From jon@callas.org Wed Feb 1 00:28:29 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8F721F84F8 for ; Wed, 1 Feb 2012 00:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfVJJgxyxLn0 for ; Wed, 1 Feb 2012 00:28:28 -0800 (PST) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 407C221F84F5 for ; Wed, 1 Feb 2012 00:28:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 744F42F1DBD for ; Wed, 1 Feb 2012 00:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Kr3noTMAkn4 for ; Wed, 1 Feb 2012 00:28:26 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 74D232F1DB3 for ; Wed, 1 Feb 2012 00:28:26 -0800 (PST) Received: from [10.0.23.88] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 01 Feb 2012 00:28:26 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 01 Feb 2012 00:28:26 -0800 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Jon Callas In-Reply-To: Date: Wed, 1 Feb 2012 00:28:25 -0800 Message-Id: <686A6224-3CB0-4BD8-8E32-9389689EC7E6@callas.org> References: <62F4ED71-4893-458D-B2F1-0651D85ACE3A@bbn.com> <4F21B25C.7070406@fifthhorseman.net> <20120126210653.GU16280@mail.yitter.info> <84A92419-9A72-41FA-BDD8-4E096EC5A952@virtualized.org> <14A0F2F6-E953-4C32-848F-22DEDB0A60A0@bbn.com> To: therightkey@ietf.org X-Mailer: Apple Mail (2.1251.1) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 08:28:29 -0000 On Jan 31, 2012, at 7:35 PM, Phillip Hallam-Baker wrote: > I don't see the problem with defining the term 'trustworthy' >=20 > Risk =3D Cost imposed by likelihood of probable loss. > Trust =3D Confidence with which risk is assessed. > Trusted =3D An entity that is relied on to mitigate risk (whether > trustworthy or not). > Trustworthy =3D An entity that meets rational criteria for risk = mitigation. >=20 > We could wordsmith the definitions, but I think we can probably agree > on the general principles. >=20 > The problems stem from the fact that risk is a very complex function. > It is not merely probability * probable loss since in a real world > situation both are continuous functions, I might suffer $100 loss > with probability X, and a $1000 loss with probability Y and so on. >=20 > And it is not just the expected loss that is the issue but the cost > that expected loss would impose on my business. My probability of a $1 > million loss might be 0.1% but the cost that potential imposes on my > business might be much higher than $1000. >=20 >=20 > I think we should also be able to come to agreement that even though > we can define the terms, we can't expect to come to precise > measurements, or even particularly satisfactory measurements. If we > could do that we would be in the regular business of insurance. >=20 > In particular, insurance companies have always avoided writing > policies on acts of war. The reason being that the probable losses > simply do not follow a predictable pattern. Losses due to theft and > even natural causes follow reasonably predictable patterns. >=20 > We are now dealing with politically motivated attacks and so we end up > with probabilities that don't fit a mathematical model and losses that > don't have a monetary value. I don't buy it. You're presuming that risk and trust exist in a vacuum and can be = measured context-free. Trust, you see, is transitive. Not transitive in the mathematical sense, = but transitive in the grammatical sense -- it needs a direct object. You might trust your mother, but do you trust your mother to set up your = VPN?=20 The flip side of this is risk, and indeed risk is colloquially just = trust with the polarity inverted. Or perhaps risk is 1 - trust. Most strictly speaking, risk is uncertainty, but we often think risk is = danger. Under a strict definition of risk, jumping off the top of a = skyscraper is isn't risky; in all likelihood, you'll end up dead. But = jumping out of a second floor window is very risky because you might end = up dead or you might tuck and roll with impunity. Similarly, I trust you'll just be a splat from the skyscraper leap, but = I can hardly use the word at all with the jump from the window. Things = are riskiest when you might as well guess, it means that the probability = is close to 1/2. Trust, in contrast is an approximation of certainty, = and either end of the scale is trust. And keys are just labels. I'm enough of an SPKI revanchist to say that = keys are just names or labels. You can no more determine trustworthiness = from a mere name than you can tell a book by its cover. To talk about = trust, let alone trust*worththiness*, you're talking reputation. And = what we mean by reputation is not merely certainty but certainty of a = desirable outcome. Reputation and risk diverge when there's a low risk = of a good outcome. That's why we really shouldn't touch it, unless we're going to truly = talk about the counterintuitiveness of a bad reputation being one that = has low risk. Jon From aerowolf@gmail.com Wed Feb 1 05:32:05 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F79711E81F3 for ; Wed, 1 Feb 2012 05:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=-2.538, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Dqc3XTUOyfg for ; Wed, 1 Feb 2012 05:32:04 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B91411E81DC for ; Wed, 1 Feb 2012 05:32:04 -0800 (PST) Received: by ggnq2 with SMTP id q2so665385ggn.31 for ; Wed, 01 Feb 2012 05:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=Dk7wUdEhA5YTH4G9mU8DnjIHz9gHZ4fFQYxIYgpFP0Y=; b=L+joJUhgs4/fXHRSO+iRNIbvwQbAG5fFVQzm8HeF+JWLwKNUIJzpilxXB5TlF/jlqS BAmhY1Vd8zxnCbuVv/IADnLe07EPyDoeTyvw5591lT/REsH/ViuMCeCqnV50zMf5YCgx K32gO1YGham2esYFVofqs3rHulcFSrLkE2mxg= Received: by 10.50.77.234 with SMTP id v10mr6766013igw.29.1328103123723; Wed, 01 Feb 2012 05:32:03 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id wn6sm14471735igb.3.2012.02.01.05.31.59 (version=SSLv3 cipher=OTHER); Wed, 01 Feb 2012 05:32:00 -0800 (PST) From: "Kyle Hamilton" To: "Phillip Hallam-Baker" Date: Wed, 1 Feb 2012 05:31:54 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgy4eaxfrot27u4oq2k2 Cc: therightkey@ietf.org, Jon Callas Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 13:32:05 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgy4eaxfrot27u4oq2k2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 SSBkbyBzZWUgYSBwcm9ibGVtIHdpdGggZGVmaW5pbmcgdGhlIHRlcm0gJ3RydXN0d29ydGh5Jywg YmVjYXVzZSBpdCdzIHJlaW52ZW50aW5nIHRoZSB3aGVlbC4gSXQncyBhbHJlYWR5IGJlZW4gZGVm aW5lZCBpbiBsYXcgYXMgImZpZHVjaWFyeSIuICBUaGlzIGlzIHRoZSBraW5kIG9mIHJlbGF0aW9u c2hpcCB5b3UgaGF2ZSB3aXRoIHlvdXIgZG9jdG9yLCB5b3VyIGxhd3llciwgeW91ciBhY2NvdW50 YW50LCB5b3VyIGJhbmssIHlvdXIgaW5zdXJhbmNlIGNvbXBhbnksIGV2ZW4geW91ciBjZW1ldGFy eSwgZXZlcnkgb25lIG9mIHRoZW0gcmVndWxhdGVkIHRvIGEgbWluaW11bSBzdGFuZGFyZCBvZiBw cm9mZXNzaW9uYWwgY29tcGV0ZW5jZSB0byBwcm90ZWN0IHlvdXIgcmVsYXRpb25zaGlwcyB3aXRo IHRoZW0gZnJvbSBkaXNjbG9zdXJlLg0KDQpUaGVyZSdzIGF0IGxlYXN0IG9uZSBVUyBzdGF0ZSAo TmV2YWRhKSB3aGljaCBoYXMgbGF3cyB3aGljaCByZWxhdGUgdG8gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdGllcyAoTlJTIGNoYXB0ZXIgNzIwKS4gIFRoZWlyIGltcGxlbWVudGluZyByZWd1bGF0aW9u cyAoTkFDIDcyMCkgYXJlIHZlcnkgc3Ryb25nIGFuZCB3ZWxsLWRlc2lnbmVkLCBhbmQgZm9jdXMg b24gdGhlIHRoaW5ncyB0aGF0IHNob3VsZCBiZSBmb2N1c2VkIG9uIGZvciBDQXMgKGluY2x1ZGlu ZyBsaWNlbnNlcykuICBUaGUgZG93bnNpZGUgaXMgdGhhdCBpdCdzIGEgJDEwayBmZWUgZm9yIHRo ZSBsaWNlbnNlLCBhbm51YWxseSwgYW5kIEkgaGF2ZSBubyBpZGVhIGhvdyBhbnlvbmUgY291bGQg YmUgZXhwZWN0ZWQgdG8gbWFrZSBhbnkga2luZCBvZiBwcm9maXRhYmxlIGJ1c2luZXNzIGluIHRo b3NlIGNvbmRpdGlvbnMuDQoNCldlJ3JlIGRldmVsb3Bpbmcgc3lzdGVtcyB3aGljaCBuZWVkIHRv IHdvcmsgaW4gdGhlIHJlYWwgd29ybGQuICBUaGUgcmVhbCB3b3JsZCBhbHJlYWR5IGtub3dzIGhv dyB0byBkZWFsIHdpdGggcGFwZXIsIGFuZCB0aGUgY291cnRzIGFscmVhZHkga25vdyBob3cgdG8g ZGVhbCB3aXRoIHBhcGVyLiAgV2hhdCB3ZSBuZWVkIHRvIGRvIGlzIGZpZ3VyZSBvdXQgYSBtZWFu cyB0byBicmluZyBjcnlwdG8gcHJhY3RpY2UgbW9yZSBpbiBsaW5lIHdpdGggdGhlIGtpbmRzIG9m IGR1ZSBkaWxpZ2VuY2UgYW5kIHByaXZhY3kgYWxyZWFkeSBleHBlY3RlZCBvZiBwYXBlci4gIElu IHRoZSBVUywgaXQncyBhIGZlbG9ueSB0byB0YW1wZXIgd2l0aCBvciBpbnRlcmZlcmUgd2l0aCB0 aGUgZGVsaXZlcnkgb2YgcGFwZXIgbWFpbCAoUG9zdGFsIEFjdCkuICBJdCdzIGFsc28gYSBmZWxv bnkgdG8gYXR0ZW1wdCB0byBieXBhc3MgYSB0ZWNobm9sb2dpY2FsIHByb3RlY3Rpb24gbWVhc3Vy ZSwgc3VjaCBhcyBlbmNyeXB0aW9uIChETUNBKS4gIEl0J3Mgbm90IGEgZmVsb255IHRvIHJlYWQg dW5lbmNyeXB0ZWQgYml0cyBvbiB0aGUgd2lyZS4gIFNob3VsZG4ndCB3ZSBiZSB0cnlpbmcgdG8g Y3JlYXRlIHN0cm9uZ2VyIHByb3RlY3Rpb25zIGZvciBvdXIgdXNlcnMsIGluc3RlYWQgb2Ygd3Jh bmdsaW5nIG92ZXIgcG9vcmx5IHJlaW52ZW50aW5nIHRoZSBicml0dGxlIHdoZWVsPw0KDQotS3ls ZSBIDQoNCk9uIFR1ZSwgSmFuIDMxLCAyMDEyIGF0IDc6MzUgUE0sIFBoaWxsaXAgSGFsbGFtLUJh a2VyIDxoYWxsYW1AZ21haWwuY29tPiB3cm90ZToNCj4gSSBkb24ndCBzZWUgdGhlIHByb2JsZW0g d2l0aCBkZWZpbmluZyB0aGUgdGVybSAndHJ1c3R3b3J0aHknDQo+DQo+IFJpc2sgPSBDb3N0IGlt cG9zZWQgYnkgbGlrZWxpaG9vZCBvZiBwcm9iYWJsZSBsb3NzLg0KPiBUcnVzdCA9IENvbmZpZGVu Y2Ugd2l0aCB3aGljaCByaXNrIGlzIGFzc2Vzc2VkLg0KPiBUcnVzdGVkID0gQW4gZW50aXR5IHRo YXQgaXMgcmVsaWVkIG9uIHRvIG1pdGlnYXRlIHJpc2sgKHdoZXRoZXINCj4gdHJ1c3R3b3J0aHkg b3Igbm90KS4NCj4gVHJ1c3R3b3J0aHkgPSBBbiBlbnRpdHkgdGhhdCBtZWV0cyByYXRpb25hbCBj cml0ZXJpYSBmb3IgcmlzayBtaXRpZ2F0aW9uLg0KPg0KPiBXZSBjb3VsZCB3b3Jkc21pdGggdGhl IGRlZmluaXRpb25zLCBidXQgSSB0aGluayB3ZSBjYW4gcHJvYmFibHkgYWdyZWUNCj4gb24gdGhl IGdlbmVyYWwgcHJpbmNpcGxlcy4NCj4NCj4gVGhlIHByb2JsZW1zIHN0ZW0gZnJvbSB0aGUgZmFj dCB0aGF0IHJpc2sgaXMgYSB2ZXJ5IGNvbXBsZXggZnVuY3Rpb24uDQo+IEl0IGlzIG5vdCBtZXJl bHkgcHJvYmFiaWxpdHkgKiBwcm9iYWJsZSBsb3NzIHNpbmNlIGluIGEgcmVhbCB3b3JsZA0KPiBz aXR1YXRpb24gYm90aCBhcmUgY29udGludW91cyBmdW5jdGlvbnMsIEkgbWlnaHQgc3VmZmVyIKAk MTAwIGxvc3MNCj4gd2l0aCBwcm9iYWJpbGl0eSBYLCBhbmQgYSAkMTAwMCBsb3NzIHdpdGggcHJv YmFiaWxpdHkgWSBhbmQgc28gb24uDQo+DQo+IEFuZCBpdCBpcyBub3QganVzdCB0aGUgZXhwZWN0 ZWQgbG9zcyB0aGF0IGlzIHRoZSBpc3N1ZSBidXQgdGhlIGNvc3QNCj4gdGhhdCBleHBlY3RlZCBs b3NzIHdvdWxkIGltcG9zZSBvbiBteSBidXNpbmVzcy4gTXkgcHJvYmFiaWxpdHkgb2YgYSAkMQ0K PiBtaWxsaW9uIGxvc3MgbWlnaHQgYmUgMC4xJSBidXQgdGhlIGNvc3QgdGhhdCBwb3RlbnRpYWwg aW1wb3NlcyBvbiBteQ0KPiBidXNpbmVzcyBtaWdodCBiZSBtdWNoIGhpZ2hlciB0aGFuICQxMDAw Lg0KPg0KPg0KPiBJIHRoaW5rIHdlIHNob3VsZCBhbHNvIGJlIGFibGUgdG8gY29tZSB0byBhZ3Jl ZW1lbnQgdGhhdCBldmVuIHRob3VnaA0KPiB3ZSBjYW4gZGVmaW5lIHRoZSB0ZXJtcywgd2UgY2Fu J3QgZXhwZWN0IHRvIGNvbWUgdG8gcHJlY2lzZQ0KPiBtZWFzdXJlbWVudHMsIG9yIGV2ZW4gcGFy dGljdWxhcmx5IHNhdGlzZmFjdG9yeSBtZWFzdXJlbWVudHMuIElmIHdlDQo+IGNvdWxkIGRvIHRo YXQgd2Ugd291bGQgYmUgaW4gdGhlIHJlZ3VsYXIgYnVzaW5lc3Mgb2YgaW5zdXJhbmNlLg0KPg0K PiBJbiBwYXJ0aWN1bGFyLCBpbnN1cmFuY2UgY29tcGFuaWVzIGhhdmUgYWx3YXlzIGF2b2lkZWQg d3JpdGluZw0KPiBwb2xpY2llcyBvbiBhY3RzIG9mIHdhci4gVGhlIHJlYXNvbiBiZWluZyB0aGF0 IHRoZSBwcm9iYWJsZSBsb3NzZXMNCj4gc2ltcGx5IGRvIG5vdCBmb2xsb3cgYSBwcmVkaWN0YWJs ZSBwYXR0ZXJuLiBMb3NzZXMgZHVlIHRvIHRoZWZ0IGFuZA0KPiBldmVuIG5hdHVyYWwgY2F1c2Vz IGZvbGxvdyByZWFzb25hYmx5IHByZWRpY3RhYmxlIHBhdHRlcm5zLg0KPg0KPiBXZSBhcmUgbm93 IGRlYWxpbmcgd2l0aCBwb2xpdGljYWxseSBtb3RpdmF0ZWQgYXR0YWNrcyBhbmQgc28gd2UgZW5k IHVwDQo+IHdpdGggcHJvYmFiaWxpdGllcyB0aGF0IGRvbid0IGZpdCBhIG1hdGhlbWF0aWNhbCBt b2RlbCBhbmQgbG9zc2VzIHRoYXQNCj4gZG9uJ3QgaGF2ZSBhIG1vbmV0YXJ5IHZhbHVlLg0KPg0K Pg0KPiBPbiBUdWUsIEphbiAzMSwgMjAxMiBhdCA3OjI5IFBNLCBKb24gQ2FsbGFzIDxqb25AY2Fs bGFzLm9yZz4gd3JvdGU6DQo+Pg0KPj4gT24gSmFuIDI2LCAyMDEyLCBhdCAyOjU1IFBNLCBSaWNo YXJkIEwuIEJhcm5lcyB3cm90ZToNCj4+DQo+Pj4+Pj4gQXMgc2VjdXJpdHkgZW5naW5lZXJzLCBv dXIgcm9sZSBpcyB0byAoYSkgcmVkdWNlIHRoZSBudW1iZXIgb2YNCj4+Pj4+PiBlbnRpdGllcyB3 ZSB0cnVzdDsgKGIpIHJlZHVjZSB0aGUgZXh0ZW50IHRvIHdoaWNoIHdlIHRydXN0IHRoZQ0KPj4+ Pj4+IHJlbWFpbmluZyB0cnVzdGVkIGVudGl0aWVzOyBhbmQgKGMpIGRldGVybWluZSB0aGUgdHJ1 c3R3b3J0aGluZXNzIG9mDQo+Pj4+Pj4gdHJ1c3RlZCBlbnRpdGllcy4NCj4+Pj4+DQo+Pj4+PiBS ZWFsbHk/DQo+Pj4+DQo+Pj4+IFllcC4NCj4+Pg0KPj4+ICsxDQo+Pj4NCj4+PiBPbmUgb2YgdGhl IGJldHRlciBkZWZpbml0aW9ucyBJJ3ZlIGhlYXJkLiCgSSB3b3VsZCBxdWVzdGlvbiB3aGV0aGVy IChjKSBpcyBldmVuIGluIHNjb3BlOyBzZWVtcyBsaWtlIGEgcmVseWluZyBwYXJ0eSBmdW5jdGlv bi4NCj4+DQo+PiBXZSBzaG91bGQgcnVuIHNjcmVhbWluZyBmcm9tIChjKS4gTm90IG9ubHkgZG8g dGhlcmUgYmUgZHJhZ29ucyB0aGVyZSwgYnV0IHRoZXJlIGJlIGRyYWdvbnMgZXZlbiBpbiBzYXlp bmcgd2hhdCAidHJ1c3R3b3J0aGluZXNzIiBtZWFucy4gU3VyZWx5IHRoaXMgaXMgbm90IGEgcmVh bC13b3JsZCByZXB1dGF0aW9uIHN5c3RlbS4NCj4+DQo+PiCgIKAgoCCgSm9uDQo+Pg0KPj4NCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiB0aGVy aWdodGtleSBtYWlsaW5nIGxpc3QNCj4+IHRoZXJpZ2h0a2V5QGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RoZXJpZ2h0a2V5DQo+DQo+DQo+DQo+IC0t DQo+IFdlYnNpdGU6IGh0dHA6Ly9oYWxsYW1iYWtlci5jb20vDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRoZXJpZ2h0a2V5IG1haWxpbmcgbGlz dA0KPiB0aGVyaWdodGtleUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RoZXJpZ2h0a2V5DQoNCg== --gmsm1.9.5eqgy4eaxfrot27u4oq2k2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMDExMzMxNTRaMCMGCSqGSIb3DQEJBDEWBBTHBf/hb9n4sFlNqqBa+1eG Cy6LcjBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAGV3nQqaB36COzwzHxUksY7O+V8cOk723S4WQCdXWZaOmgsjrMcHpXZdGVGIvJ8HqmX2Y skGla3I23MbFuij4DfCTNx0cLrhyJwvjL7uSm+wpkRIIf3wpvyXrQ1HRU9fzJSxOqg6R7tVSeY6t e4HHhzR48Xy/LZSgMozzqX6qJGUoBWtLMRQNZB2eLS2EpVG8q2abEABbJ17Xp+Hc6qj9czOFasF6 LkmFuzWM7upUWmG6q17rh8dRKvF6KlvlppbYzj9aUI+brqwL5BLhqQ9bearPK0ejl6GuYlzxR54M p6QO5mqlwj4bt8PncdDiZOxYQNseMbIwyGmdmxOhYuZLCwAAAAAAAA== --gmsm1.9.5eqgy4eaxfrot27u4oq2k2-- From ietf@hardjono.net Wed Feb 1 08:35:37 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923D321F8C7B for ; Wed, 1 Feb 2012 08:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpAKxe-FbGui for ; Wed, 1 Feb 2012 08:35:36 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 9FA1C21F8C75 for ; Wed, 1 Feb 2012 08:35:36 -0800 (PST) Received: (qmail 12230 invoked by uid 0); 1 Feb 2012 16:35:34 -0000 Received: from unknown (HELO box602.bluehost.com) (70.40.220.102) by cpoproxy2.bluehost.com with SMTP; 1 Feb 2012 16:35:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hardjono.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=J4xIb4sg0sB6wqjOj6qtssCYTwjfaZq5YlMcIwOWWsQ=; b=AmnaxRtbkt5Rx9QY+KkSPc78qu/sNK58h0h3nlrilyNXdMaaQg4R8wQ5heON2uTR1e0uyIzTbNMtSeNor/RK0nsxSBGAXkj0bwh6dWQLdYUpBr9bTlHRRHOxnBNxM3N7; Received: from [18.189.89.161] (helo=WINCE7P9IL9EJ0) by box602.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Rsd9h-00085e-VZ for therightkey@ietf.org; Wed, 01 Feb 2012 09:35:34 -0700 From: "Thomas Hardjono" To: References: <62F4ED71-4893-458D-B2F1-0651D85ACE3A@bbn.com> <4F21B25C.7070406@fifthhorseman.net> <20120126210653.GU16280@mail.yitter.info> <84A92419-9A72-41FA-BDD8-4E096EC5A952@virtualized.org> <14A0F2F6-E953-4C32-848F-22DEDB0A60A0@bbn.com> <686A6224-3CB0-4BD8-8E32-9389689EC7E6@callas.org> In-Reply-To: <686A6224-3CB0-4BD8-8E32-9389689EC7E6@callas.org> Date: Wed, 1 Feb 2012 11:35:32 -0500 Message-ID: <000401cce0ff$8528aee0$8f7a0ca0$@hardjono.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLANCB/s64RBC4n9l7QLvFPhLI2xgJ7sNWmAdk4rFQCD4JUYwGEyY8iAxJSHQIBYYM42QFocRICAr8um5QCMjBpuQKYOct7Ai4HvKcBXc9ZmJN6uzGw Content-Language: en-us X-Identified-User: {3727:box602.bluehost.com:hardjono:hardjono.net} {sentby:smtp auth 18.189.89.161 authed with ietf@hardjono.net} Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 16:35:37 -0000 > -----Original Message----- > From: therightkey-bounces@ietf.org [mailto:therightkey- > bounces@ietf.org] On Behalf Of Jon Callas > Sent: Wednesday, February 01, 2012 3:28 AM > To: therightkey@ietf.org > Subject: Re: [therightkey] Will the real RPF please stand up? >=20 >=20 > On Jan 31, 2012, at 7:35 PM, Phillip Hallam-Baker wrote: >=20 > > I don't see the problem with defining the term 'trustworthy' > > > > Risk =3D Cost imposed by likelihood of probable loss. > > Trust =3D Confidence with which risk is assessed. > > Trusted =3D An entity that is relied on to mitigate risk (whether > > trustworthy or not). > > Trustworthy =3D An entity that meets rational criteria for risk > mitigation. > > > > We could wordsmith the definitions, but I think we can probably agree > > on the general principles. > > > > The problems stem from the fact that risk is a very complex function. > > It is not merely probability * probable loss since in a real world > > situation both are continuous functions, I might suffer $100 loss > > with probability X, and a $1000 loss with probability Y and so on. > > > > And it is not just the expected loss that is the issue but the cost > > that expected loss would impose on my business. My probability of a > $1 > > million loss might be 0.1% but the cost that potential imposes on my > > business might be much higher than $1000. > > > > > > I think we should also be able to come to agreement that even though > > we can define the terms, we can't expect to come to precise > > measurements, or even particularly satisfactory measurements. If we > > could do that we would be in the regular business of insurance. > > > > In particular, insurance companies have always avoided writing > > policies on acts of war. The reason being that the probable losses > > simply do not follow a predictable pattern. Losses due to theft and > > even natural causes follow reasonably predictable patterns. > > > > We are now dealing with politically motivated attacks and so we end > up > > with probabilities that don't fit a mathematical model and losses > that > > don't have a monetary value. >=20 > I don't buy it. > [cut] >=20 > And keys are just labels. I'm enough of an SPKI revanchist to say that > keys are just names or labels. You can no more determine > trustworthiness from a mere name than you can tell a book by its cover. > To talk about trust, let alone trust*worththiness*, you're talking > reputation. And what we mean by reputation is not merely certainty but > certainty of a desirable outcome. Reputation and risk diverge when > there's a low risk of a good outcome. >=20 > That's why we really shouldn't touch it, unless we're going to truly > talk about the counterintuitiveness of a bad reputation being one that > has low risk. >=20 > Jon >=20 Phil, I read through of your PDF docs. Jon brings-up a point related to trust and reputation. What is not shown (or simply assumed) in the Four Corners model is that a huge amount of legal foundation (what I call "Social Trust") exists in the banking world (where the four corners model exists). The folks working on the "post-Liberty" (my term) identity protocols and federation have learned over the last 10 years or so that a "Trust Framework" (ala FICAM) is needed to being together Technical Trust and Social Trust. Otherwise the eco-system simply does not start working. Bilateral contracts just don't scale. Thus what I think is missing from this proposal is a recognition for the need of a "Trust Framework" that will define the obligations of all the participants in your ecosystem (eg. the CAs, DNS server operators, ICANN, etc. etc.). Developing a Trust Framework for the next-generation internet infrastructure would be a great leap forward for the IETF. Otherwise, we just get stuck in the nuts-and-bolts of yet more "technical trust" (yet another set of protocols to do XYZ). /thomas/ __________________________________________ Thomas Hardjono MIT Kerberos Consortium email:=A0 hardjono[at]mit.edu desk:=A0=A0=A0+1 617-715-2451 __________________________________________ From jon@callas.org Wed Feb 1 09:25:52 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA71221F87F5 for ; Wed, 1 Feb 2012 09:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvaD-FurUHiQ for ; Wed, 1 Feb 2012 09:25:52 -0800 (PST) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 32CB821F87F3 for ; Wed, 1 Feb 2012 09:25:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 650AC2FA8CF; Wed, 1 Feb 2012 09:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91at+JKTV5-Q; Wed, 1 Feb 2012 09:25:49 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id B84922FA898; Wed, 1 Feb 2012 09:25:49 -0800 (PST) Received: from [10.0.23.88] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 01 Feb 2012 09:25:49 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 01 Feb 2012 09:25:49 -0800 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Jon Callas In-Reply-To: Date: Wed, 1 Feb 2012 09:25:47 -0800 Message-Id: References: To: Kyle Hamilton X-Mailer: Apple Mail (2.1251.1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: therightkey@ietf.org, Phillip Hallam-Baker , Jon Callas Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 17:25:52 -0000 On Feb 1, 2012, at 5:31 AM, Kyle Hamilton wrote: > * PGP - S/MIME Signed by an unverified key: 02/01/2012 at 05:31:54 AM >=20 > I do see a problem with defining the term 'trustworthy', because it's = reinventing the wheel. It's already been defined in law as "fiduciary". = This is the kind of relationship you have with your doctor, your lawyer, = your accountant, your bank, your insurance company, even your cemetary, = every one of them regulated to a minimum standard of professional = competence to protect your relationships with them from disclosure. I agree almost completely. It's fiduciary when you are dealing with = money. It's whatever the equivalent is when you're dealing with = information. Money is wonderful because you can always back up a system with = insurance (until you can't, as we saw with credit default swaps, etc). = But information is different because if I lose a secret of yours, I can = *never* pay you back. I cannot undo the transaction nor is it possible = to repay for the damage with money. Yeah, it can be a fine, but it's not = repayment. You can't unsink the ship that the loose lips sank. Jon From hallam@gmail.com Wed Feb 1 10:43:22 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F87911E8080 for ; Wed, 1 Feb 2012 10:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoEu-zCYCKoc for ; Wed, 1 Feb 2012 10:43:21 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B303811E8079 for ; Wed, 1 Feb 2012 10:43:19 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2019630obb.31 for ; Wed, 01 Feb 2012 10:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AvCzPALgRJ+XW5Mbd9tB2a5cH0rBvZZGHvaJy0uFI7Q=; b=kmzPEgbz6DMS6Z5ujomO8RvPZPjLIr/BbL5LkRiM9k9QegTjYiV2Jo7har+nVBykgW epE7RmHmcHivzRDxlLCvr+xvnfaP8SJH1TJaqbL3dL+pjqtF9onBXxUll2s2TXqNIIWd 3P4QNEYOni8NImesQt2CVxPiluyTVKB91QveA= MIME-Version: 1.0 Received: by 10.182.41.36 with SMTP id c4mr19308702obl.21.1328121799339; Wed, 01 Feb 2012 10:43:19 -0800 (PST) Received: by 10.182.208.7 with HTTP; Wed, 1 Feb 2012 10:43:19 -0800 (PST) In-Reply-To: <000401cce0ff$8528aee0$8f7a0ca0$@hardjono.net> References: <62F4ED71-4893-458D-B2F1-0651D85ACE3A@bbn.com> <4F21B25C.7070406@fifthhorseman.net> <20120126210653.GU16280@mail.yitter.info> <84A92419-9A72-41FA-BDD8-4E096EC5A952@virtualized.org> <14A0F2F6-E953-4C32-848F-22DEDB0A60A0@bbn.com> <686A6224-3CB0-4BD8-8E32-9389689EC7E6@callas.org> <000401cce0ff$8528aee0$8f7a0ca0$@hardjono.net> Date: Wed, 1 Feb 2012 13:43:19 -0500 Message-ID: From: Phillip Hallam-Baker To: Thomas Hardjono Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 18:43:22 -0000 That is a good point, and one that threatens to create a whole new chapter. First, replying to Jon, what we are managing is not risk itself but the cost imposed by the possibility of unintended outcomes. If the guy is jumping out of a skyscraper and does not intend to make himself into people pancake on the pavement, then he has a 100% probability of realizing a major unintended outcome. We could maybe come up with a precise term but the key point is that the objective is to minimize the costs imposed by the unintended outcomes. That is the way the system was originally designed and it is still the right way to design the system. What has changed is that a hundred million people now carry mobiles with cameras and so suddenly the dwindling number of dictatorships are discovering that they are now accountable for every atrocity their security forces commit on camera. So looking at the point Thomas raises, I think it makes the point about costs quite clearly. Alice is a patient Bob is Alice's doctor Carol is an outsource provider of patient records management systems. Alice trusts Bob with her life (quite literally). Bob has a professional duty to maintain Alice's confidentiality plus a huge business incentive to do so. As a consequence Carol has to do more than merely demonstrate to Bob that she can maintain the records more securely than Bob could by himself because Bob has to justify the situation to Alice (and hundreds of other patients). If he has to talk to every patient and it takes him 5 minutes, he has just lost a week of working time he could have been making money in. If that scheme is going to work at any level it is going to require some sort of standard controls that Carol can be evaluated against On Wed, Feb 1, 2012 at 11:35 AM, Thomas Hardjono wrote: > > >> -----Original Message----- >> From: therightkey-bounces@ietf.org [mailto:therightkey- >> bounces@ietf.org] On Behalf Of Jon Callas >> Sent: Wednesday, February 01, 2012 3:28 AM >> To: therightkey@ietf.org >> Subject: Re: [therightkey] Will the real RPF please stand up? >> >> >> On Jan 31, 2012, at 7:35 PM, Phillip Hallam-Baker wrote: >> >> > I don't see the problem with defining the term 'trustworthy' >> > >> > Risk =3D Cost imposed by likelihood of probable loss. >> > Trust =3D Confidence with which risk is assessed. >> > Trusted =3D An entity that is relied on to mitigate risk (whether >> > trustworthy or not). >> > Trustworthy =3D An entity that meets rational criteria for risk >> mitigation. >> > >> > We could wordsmith the definitions, but I think we can probably > agree >> > on the general principles. >> > >> > The problems stem from the fact that risk is a very complex > function. >> > It is not merely probability * probable loss since in a real world >> > situation both are continuous functions, I might suffer =A0$100 loss >> > with probability X, and a $1000 loss with probability Y and so on. >> > >> > And it is not just the expected loss that is the issue but the > cost >> > that expected loss would impose on my business. My probability of > a >> $1 >> > million loss might be 0.1% but the cost that potential imposes on > my >> > business might be much higher than $1000. >> > >> > >> > I think we should also be able to come to agreement that even > though >> > we can define the terms, we can't expect to come to precise >> > measurements, or even particularly satisfactory measurements. If > we >> > could do that we would be in the regular business of insurance. >> > >> > In particular, insurance companies have always avoided writing >> > policies on acts of war. The reason being that the probable losses >> > simply do not follow a predictable pattern. Losses due to theft > and >> > even natural causes follow reasonably predictable patterns. >> > >> > We are now dealing with politically motivated attacks and so we > end >> up >> > with probabilities that don't fit a mathematical model and losses >> that >> > don't have a monetary value. >> >> I don't buy it. >> [cut] >> >> And keys are just labels. I'm enough of an SPKI revanchist to say > that >> keys are just names or labels. You can no more determine >> trustworthiness from a mere name than you can tell a book by its > cover. >> To talk about trust, let alone trust*worththiness*, you're talking >> reputation. And what we mean by reputation is not merely certainty > but >> certainty of a desirable outcome. Reputation and risk diverge when >> there's a low risk of a good outcome. >> >> That's why we really shouldn't touch it, unless we're going to truly >> talk about the counterintuitiveness of a bad reputation being one > that >> has low risk. >> >> =A0 =A0 =A0 Jon >> > > Phil, > > I read through of your PDF docs. > > Jon brings-up a point related to trust and reputation. =A0What is not > shown (or simply assumed) in the Four Corners model is that a huge > amount of legal foundation (what I call "Social Trust") exists in the > banking world (where the four corners model exists). > > The folks working on the "post-Liberty" (my term) identity protocols > and federation have learned over the last 10 years or so that a "Trust > Framework" (ala FICAM) is needed to being together Technical Trust and > Social Trust. =A0Otherwise the eco-system simply does not start working. > Bilateral contracts just don't scale. > > Thus what I think is missing from this proposal is a recognition for > the need of a "Trust Framework" that will define the obligations of > all the participants in your ecosystem (eg. the CAs, DNS server > operators, ICANN, etc. etc.). =A0Developing a Trust Framework for the > next-generation internet infrastructure would be a great leap forward > for the IETF. =A0Otherwise, we just get stuck in the nuts-and-bolts of > yet more "technical trust" (yet another set of protocols to do XYZ). > > /thomas/ > > > __________________________________________ > Thomas Hardjono > MIT Kerberos Consortium > email:=A0 hardjono[at]mit.edu > desk:=A0=A0=A0+1 617-715-2451 > __________________________________________ > > > > > > > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --=20 Website: http://hallambaker.com/ From paul@marvell.com Wed Feb 1 17:21:41 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4229E1F0C40 for ; Wed, 1 Feb 2012 17:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.01 X-Spam-Level: X-Spam-Status: No, score=-6.01 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6H1kOYZ2y6BV for ; Wed, 1 Feb 2012 17:21:40 -0800 (PST) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with ESMTP id A33CD1F0C36 for ; Wed, 1 Feb 2012 17:21:39 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKTynlHtDwKM6X7FNVCW+NcwYXTMNmazTg@postini.com; Wed, 01 Feb 2012 17:21:39 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Wed, 1 Feb 2012 17:20:48 -0800 From: Paul Lambert To: Martin Millnert Date: Wed, 1 Feb 2012 17:20:48 -0800 Thread-Topic: [therightkey] Will the real RPF please stand up? Thread-Index: Aczgh2ihW+38MEJLTQWnN7naSDyWBQAmO0kg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01567643621@SC-VEXCH2.marvell.com> References: <62F4ED71-4893-458D-B2F1-0651D85ACE3A@bbn.com> <4F21B25C.7070406@fifthhorseman.net> <20120126210653.GU16280@mail.yitter.info> <84A92419-9A72-41FA-BDD8-4E096EC5A952@virtualized.org> <14A0F2F6-E953-4C32-848F-22DEDB0A60A0@bbn.com> <7BAC95F5A7E67643AAFB2C31BEE662D015676432E0@SC-VEXCH2.marvell.com> <1328062540.6161.116.camel@davinci.millnert.se> In-Reply-To: <1328062540.6161.116.camel@davinci.millnert.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "therightkey@ietf.org" , Jon Callas Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 01:21:41 -0000 SGkgTWFydGluLA0KDQpJIHRoaW5rIHdlIG1heSBhbGwgYmUgbG9va2luZyBhdCB0aGlzIGVsZXBo YW50IGZyb20gc2V2ZXJhbCBkaWZmZXJlbnQgYW5nbGVzLiAgV2UgYXJlIGhhdmluZyB0byB3cml0 ZSBlc3NheXMgb24gb3VyIHBlcnNwZWN0aXZlIHRvIGRlc2NyaWJlIHNvbWUgYnJvYWQgZ2VuZXJh bGl6YXRpb25zIHRoYXQgd2UgYXJlIG1ha2luZy4NCg0KPj4gPj4gT25lIG9mIHRoZSBiZXR0ZXIg ZGVmaW5pdGlvbnMgSSd2ZSBoZWFyZC4gIEkgd291bGQgcXVlc3Rpb24gd2hldGhlcg0KPj4gPihj KSBpcyBldmVuIGluIHNjb3BlOyBzZWVtcyBsaWtlIGEgcmVseWluZyBwYXJ0eSBmdW5jdGlvbi4N Cj4+ID4NCj4+ID5XZSBzaG91bGQgcnVuIHNjcmVhbWluZyBmcm9tIChjKS4gTm90IG9ubHkgZG8g dGhlcmUgYmUgZHJhZ29ucyB0aGVyZSwNCj4+ID5idXQgdGhlcmUgYmUgZHJhZ29ucyBldmVuIGlu IHNheWluZyB3aGF0ICJ0cnVzdHdvcnRoaW5lc3MiIG1lYW5zLg0KPj4gPlN1cmVseSB0aGlzIGlz IG5vdCBhIHJlYWwtd29ybGQgcmVwdXRhdGlvbiBzeXN0ZW0uDQo+PiA+DQo+PiA+CUpvbg0KPj4N Cj4+IFllcyEgLi4uIGJ1dCwgd2UgY2FuIGRlZmluZSAid2hvIHdlIHRydXN0IGZvciB3aGF0IiAu Li4gd2hvIGJlaW5nIGENCj5rZXksIHdoYXQgYmVpbmcgc29tZSBEb21haW4gb2YgRGlzY291cnNl IHdpdGggYXBwcm9wcmlhdGUgY29uc3RyYWludHMuDQo+Pg0KPj4gVHJ1c3R3b3J0aGluZXNzIGFz IGEgcHJvYmFiaWxpdHkgb3IgbWV0cmljIHlpZWxkcyBjb250cmFkaWN0b3J5IGFuZA0KPm5vbmRl dGVybWluaXN0aWMgZXZhbHVhdGlvbnMuDQo+Pg0KPj4gUGF1bA0KPg0KPlBhdWwsIGlzIHRoaXMg bmVjZXNzYXJpbHkgYmFkPw0KDQpJIHJlYWQgInRydXN0d29ydGhpbmVzcyIgYXMgYSBwb3RlbnRp YWwgbWV0cmljIC0gSSdkIHJhdGhlciBzZWUgYSBmb3JtYWwgZnJhbWV3b3JrIHRoYXQgd2FzIGNs b3NlIHRvIGZpcnN0IG9yZGVyIGxvZ2ljIHJhdGhlciB0aGFuIGZ1enp5IGxvZ2ljLg0KDQpUaGF0 IHNhaWQsIHJpc2sgcHJvYmFiaWxpdGllcyBtaWdodCBiZSB1c2VmdWwsIGJ1dCB0aGVzZSBzZWVt IGJldHRlciBhcyBhbiBvdmVybGF5IHRoYW4gYSBmb3VuZGF0aW9uYWwgZGVzaWduIGVsZW1lbnQu DQoNCk1vcmUgb2YgbXkgcG9pbnQgYWJvdmUgd2FzIHRoYXQgd2UgbmVlZCB0byBsb29rIGF0IHRo ZSBib3VuZHMgYW5kIGNvbnN0cmFpbnRzIG9mIHRoZSAidHJ1c3QiIHdpdGggYSBiZXR0ZXIgbW9k ZWwgdGhhbiB3ZSBoYXZlIGluIHRvZGF5J3MgUEtJLiAgRm9yIGV4YW1wbGUgbm90IGFsbCB0b3Ag bGV2ZWwga2V5cyBzaG91bGQgYmUgYWJsZSB0byBtYWtlIGFzc2VydGF0aW9ucyBhYm91dCBhbGwg cG9zc2libGUgZG9tYWlucyAtIHdlIG5lZWQgY29uc3RyYWlucy4gIFdlIG5lZWQgYSBub3Rpb24g b2YgZG9tYWlucyBvZiBkaXNjb3Vyc2UgdG8gc2VwYXJhdGUgZGlmZmVyZW50IHVzYWdlIG9mIG9m IGNyeXB0b2dyYXBoaWMgdHJ1c3QgbWVjaGFuaXNtcy4NCg0KPg0KPkFsbCB0aHJlZSBzdGF0ZW1l bnRzIGFib3ZlIGFyZSBzb3J0IG9mIGNvcnJlY3QgSU1ITy4gQSBzbGlnaHQNCj5tb2RpZmljYXRp b246DQo+ICAiQXMgc2VjdXJpdHkgKnByb3RvY29sKiBlbmdpbmVlcnMsIHdlIGhhdmUgdG8gWy4u Ll0gYW5kIChjKSwgZ2l2ZSB0aGUNCj51c2VycyB0aGUgY2FwYWNpdHkgYW5kIGFiaWxpdHkgdG8g ZW5mb3JjZSB0aGVpciBvd24gdHJ1c3QtcG9saWNpZXMsIGZvcg0KPnRoZWlyIG93biBwdXJwb3Nl cywgYWNjb3JkaW5nIHRvIHRoZWlyIG93biBkZXNpcmVzLiINCj4NCj5MZXQncyBnbyBkZWVwZXIu DQo+DQo+SSAoc3RpbGwsIHRoYW5rZnVsbHkhKSBoYXZlIHRoZSBhYmlsaXR5IHRvIHJlbW92ZSBy b290IENBJ3MgZnJvbSBteQ0KPi9ldGMvc3NsL2NlcnQgd2hlbiBJIHNlZSBmaXQgdG8gZG8gc28u IEFuZCBJIGRvIHNvLiAgQnV0IGl0J3MgZXh0cmVtZWx5DQo+Y3VtYmVyc29tZSBhbmQgb2J2aW91 c2x5ICJkb2VzIG5vdCBzY2FsZSIuICBMZXQncyBkbyBiZXR0ZXI/DQo+T2J2aW91c2x5LCBub3Qg YWxsIHVzZXJzIG9uIHRoZSBwbGFuZXQgY2FuIGJ5IGRlY3JlZSBvZiBhIHNtYWxsIGdyb3VwIGJl DQo+bWFuZGF0ZWQgdG8gdmVyaWZ5IHRydXN0IGluIHRoZSBzYW1lIG1hbm5lciwgYXQgbGVhc3Qg bm90IHZlcnkNCj5zdWNjZXNzZnVsbHkuIFRoZSBjaG9pY2Ugb2Ygd2hhdCB5b3Ugd2FudCB0byB0 cnVzdCBoYXMgYWx3YXlzIGJlZW4NCj50aGVyZS4NCj4NCj5Gcm9tIHRoaXMgSSBjYW4ndCBzYXkg dGhhdCBJIGVpdGhlciBmdWxseSAtIG9yIG5vdCBhdCBhbGwgLSB0cnVzdCBhbnkgQ0ENCj5pbiBt eSByb290LWNlcnQgc3RvcmUgb24gYW4gaW5kaXZpZHVhbCBiYXNpcyAtLSBzb21lIGFyZSBldmVu IHRoZXJlLCBub3QNCj5iZWNhdXNlIEkgdHJ1c3QgdGhlbSBpbmRlZmluaXRlbHksIGJ1dCBiZWNh dXNlIG9mIGEgY29tYmluYXRpb24gb2YNCj4gYSkgbXkgYnJvd3NlciBiZWNvbWVzIGZ1bGwgb2Yg ZXh0cmEgY2xpY2tzIHdpdGhvdXQgdGhlbSwNCj4gYikgdGhleSBkbyBwcm92aWRlIGEgdmFyeWlu Zy1idXQtZ3JlYXRlci10aGFuLXplcm8gJSBleHBlY3RhdGlvbiB0aGF0IGENCj5UTFMtY29ubmVj dGlvbiB0aGF0IHZhbGlkYXRlcyB0byB0aGVtIGNhbiBiZSByZWFzb25hYmx5IGV4cGVjdGVkIG5v dCB0bw0KPmFsc28gYmUgTUlUTTplZCBzb21ld2hlcmUuDQoNClllcyAuLi4gUEtJIHdpdGggbG90 cyBvZiByb290cyBpbiBicm93c2VycyBpcyBicm9rZW4uICANCg0KSW5kaXZpZHVhbCBwb2ludHMg b2YgdHJ1c3QgKGtleXMpIHNob3VsZCBiZSBhYmxlIHRvIGJlIGFkZGVkIGFuZCBkZWxldGVkIGJ5 IHRoZSBvd25lciBvZiB0aGUgc3lzdGVtLiAgRWFjaCBrZXkgc2hvdWxkIGhhdmUgc3BlY2lmaWMg bGltaXRhdGlvbnMgb24gaXQncyBkb21haW4gb2YgZGlzY291cnNlIHdpdGggY29uc3RyYWlucyBw b3NzaWJsZSB3aXRoaW4gZWFjaCBkb21haW4gKGUuZy4gY29kaW5nIHNpZ25pbmcgdmVyc3VzIERO UykNCg0KPg0KPlRoaXMgZG9lc24ndCBtZWFuICpJKiBoYXZlIDEwMCUgdHJ1c3QgaW4gYW55IG9m IHRoZW0uICBUaGVzZSBhcmUNCj5kaWZmZXJlbnQgdGhpbmdzLg0KPg0KPkFkZGluZyB0byB0aGF0 OiBoYXZpbmcgbXVsdGlwbGUgaW5wdXRzIHRvIHlvdXIgdHJ1c3QgcG9saWN5IGdlbmVyYXRpb24N Cj5lbmdpbmUsIGFzIGhhcyBiZWVuIGRpc2N1c3NlZCBoZXJlLCBjYW4ndCBwb3NzaWJseSBodXJ0 IHRoZSBvYmplY3RpdmUNCj5oZXJlPyAgU2ltaWxhcmx5LCBoYXZpbmcgYW4gb3V0cHV0IGZyb20g dGhpcyB0cnVzdCByZXNvbHV0aW9uIGVuZ2luZQ0KPnRoYXQgbW90aXZhdGVzIGl0cyBjYWxjdWxh dGlvbiAoYWNjb3JkaW5nIHRvIHlvdXIgcG9saWN5KSwgY2FuJ3QgaHVydA0KPmVpdGhlcj8NCj4N Cj4gIGNvbmZpZ3VyYXRpb24gYmFyID0gbGlzdCBvZiB2YXJpb3VzIGlucHV0IHNvdXJjZXM7DQo+ ICB0cnVzdF9wb2xpY3lfY29tcGlsZShwb2xpY3kgZm9vLCBjb25maWd1cmF0aW9uIGJhcikgLT4N Cj50cnVzdF9yZXNvbHZlX2RhdGFbcG9saWN5PWZvb10NCj4NCj4oUG9saWN5IGFuZCBjb25maWd1 cmF0aW9uIG1heSBhY3R1YWxseSBqdXN0IGJlIG9uZSBhbmQgdGhlIHNhbWUuKQ0KPg0KPk9idmlv dXNseSwgYSBjb21wdXRlciBwcm9ncmFtIHdvdWxkbid0IHdvcmsgdmVyeSB3ZWxsIGlmIGEgNjcl IHRydXN0DQo+aW1wbGllcyB0aGF0IGl0IHNob3VsZCBwcm9jZWVkIHdpdGggYSBjb21wdXRhdGlv biBpbiA2NyUgb2YgdGhlDQo+aW5zdGFuY2VzOg0KPiAgVGhlIHZhbGlkYXRpb24gcmVzdWx0IHRo cm91Z2ggbXkgdHJ1c3QgdmVyaWZpY2F0aW9uIGVuZ2luZSB1c2luZw0KPnBvbGljeSBYIG91Z2h0 IHRvIGJlIHRoYXQgSSBlaXRoZXIgY2FuIChiYXNlZCBvbiBteSBwb2xpY3khKSBwcm9jZWVkDQo+ d2l0aCB0aGUgY29tcHV0YXRpb24sIG9yLCB0aGF0IEkgaGF2ZSB0byBhYm9ydCBpdCBiZWNhdXNl IG9mIGEgbGFjayBvZg0KPnRydXN0Lg0KPg0KPiAgdmFsaWRhdGVfd2l0aF9wb2xpY3kodHJ1c3Rf cmVzb2x2ZV9kYXRhIGRhdGEsIHBvbGljeSBmb28sIGNlcnRpZmljYXRlDQo+YmFyKSAtPiAodmFs aWR8aW52YWxpZCwge2RldGFpbHN9KQ0KPg0KPlRoZSBwb2xpY3kgY2FuIGRlZmluZSB0aGluZ3Mg c3VjaCBhcywgYSA+WCUgZmFpbC1yYXRlIGZyb20NCj5jb252ZXJnZW5jZS9vYnNlcnZhdG9yeSAo dXNpbmcgY29udmVyZ2VuY2Uvb2JzZXJ2YXRvcnktY29uZmlndXJhdGlvbg0KPmZvb2Jhci4uLikg LT4gaW52YWxpZCBjZXJ0IHZlcmlmaWNhdGlvbiwgYW5kIGxpc3Qgb2Ygcm9vdC1DQSdzLCBldGMu DQo+Tm90ZSB0aGF0IHRoaXMgZG9lcyBub3QgYXQgYWxsIGV4Y2x1ZGUgcHV0dGluZyBtdWx0aXBs ZSBjZXJ0aWZpY2F0ZXMgaW4NCj50aGUgaGFuZHNoYWtlISBUaGF0IHNlZW1zIHNtYXJ0LCBmb3Ig dGhvc2Ugd2hvIGNhbiBhZmZvcmQgdGhlIGV4dHJhDQo+Ynl0ZXMgdHJhbnNmZXJyZWQuDQoNClRo aXMgaXMgd2hlcmUgSSBkb24ndCBzZWUgaG93IHVzZXJzIHdpbGwgZnVsbHkgdW5kZXJzdGFuZCBh ICUgb3IgYW5hbG9nIG1ldHJpYy4gIEkgY2FuDQogc2VlIHJlc3VsdHMgb2YgLSBZZXMsIE5vLCBj YW4ndCB0ZWxsL3Jlc29sdmUsIGV0Yy4uLg0KDQpXZSBuZWVkIHRvIHN0ZXAgYmFjayBhIGxpdHRs ZSB0byBnZXQgYSB3aWRlciB2aWV3LiAgQSAidHJ1c3QiIG1ldHJpYyANCmlzIG5vdCB0aGUgZW5k IHJlc3VsdC4gIFdFIGFyZSBidWlsZGluZyBzeXN0ZW1zIHRvIGFuc3dlciBwb2xpY3kgcXVlc3Rp b25zLg0KTGlrZSBhbiBvcmFjbGUgLSB0aGUgbWFjaGluZXJ5IHdlIGRlZmluZSBuZWVkcyB0byBn aXZlIGFuIGFuc3dlciB0bw0KcXVlc3Rpb25zIHBvc2VkLiBRdWVzdGlvbnMgbWlnaHQgYmUgb2Yg dGhlIGZvcm06IA0KIkRvZXMgKnRoaXNfa2V5IGhhdmUgRE5TYWRkcmVzcyBmb28uY29tPw0KDQoN Cj4NCj5TbywgcGVyaGFwcyBoYXZpbmcgYnJvd3NlciB2ZW5kb3JzIGFuZCBvcGVyYXRpbmcgc3lz dGVtcyBkZWNsYXJlIHdobyBUaGUNCj5saXN0IG9mIHRydXN0d29ydGh5IGVudGl0aWVzIGFjY29y ZGluZyB0byB0aGVpciBQcm9jZXNzIGlzLCBpcyBub3QgdGhlDQo+YmVzdCBzb2x1dGlvbiBmb3Ig YWxsIHB1cnBvc2VzPyAgSGF2aW5nIGRlZmF1bHRzIGlzIGZpbmUsIEkgZ3Vlc3MsIGJ1dA0KPmZv ciBhbGwgSSBjYXJlIHRoaXMgZW50aXJlIGFwcGFyYXR1cyBjb3VsZCAoc3VjY2Vzc2Z1bGx5LCBv dmVyYWxsLCBJDQo+YmV0KSBiZSBleHRlcm5hbGl6ZWQgdG8gaW5zdGl0dXRpb25zIGRlYWxpbmcg bW9yZSBzb2xlbHkgd2l0aCB0cnVzdCwgYW5kDQo+aW5kaXZpZHVhbCB1c2VycyB3b3VsZCB0aGVu IGdldCB0aGUgb3B0aW9uIHRvIGNob29zZSBiZXR3ZWVuIHRoZXNlLiBUaGUNCj5mZWVkYmFjay1s b29wIHRoaXMgY291bGQgcHJvdmlkZSBpcyBub3Qgd2l0aG91dCBtZXJpdC4NCj4gIEZvciBleGFt cGxlLCB0aGVyZSBhcHBlYXJzIHRvIG1lIHRvIGJlIGEgbmF0dXJhbCBwbGFjZSBmb3Igc29tZW9u ZSB0bw0KPmRlZmluZSB0aGVzZSBmb28ncywgdGhhdCB1c2VycyBjYW4gdXNlLiBBbmQgYWxzbyBb aW5wdXRsaXN0XQ0KPmNvbmZpZ3VyYXRpb25zLg0KDQpGZWVkYmFjayBpcyBhIGRpZmZlcmVudCBt YXR0ZXIgLi4uIG1ldHJpY3MgbWlnaHQgYmUgcG9zc2libGUgZm9yIG1vcmUgc3ViamVjdGl2ZSBv YnNlcnZhdGlvbnMgYWJvdXQgdGhlIGJlaGF2aW9yIG9mIGEga2V5J3Mgb3duZXIuICBJIHRoaW5r IHdlIGhhdmUgZGlmZmVyZW50IHVuZGVybHlpbmcgbW9kZWxzLiAgRGV0ZXJtaW5hdGlvbiBvZiB0 aGUgdmFsaWRpdHkgb2YgdGhlIHNzc2lnbm1lbnQgb2YgYXR0cmlidXRlcyAobGlrZSBhIG5hbWUg b3IgY2FwYWJpbGl0eSkgaGFzIGEgc21hbGwgZW51bWVyYXRlZCBzZXQgb2YgcmVzdWx0cy4NCg0K QWdncmVnYXRpb24gb2Ygb3RoZXIgYXR0cmlidXRlIHR5cGVzIChyaXNrLCByYXRpbmcsIHBlcmNl aXZlZCB2YWx1ZSwgcmVwdXRhdGlvbiwgZXRjKSBjb3VsZCBiZSBzdWNoIGEgbWV0cmljLiAgSXQg bWlnaHQgYmUgcG9zc2libGUgdG8gaGF2ZSBhIHBvbGljeSB0aGF0IHVzZWQgdGhlc2UgdHlwZSBv ZiBhdHRyaWJ1dGVzIChlLmcuIGVhdCBhdCByZXN0YXVyYW50IG9ubHkgaWYgcmF0aW5nIGdyZWF0 ZXIgdGhhbiB4KS4gVXNlIG9yIG5vbi11c2Ugb2YgYSBuYW1lIChwZXIgbW9zdCBvZiBvdXIgZGlz Y3Vzc2VkIGV4YW1wbGVzIHJlbGF0aW5nIHRvIFRMUyBhbmQgRE5TIG5hbWVzKSBkb2VzIG5vdCBz ZWVtIGxpa2UgYSBnb29kIHBsYWNlIHRvIGhhdmUgYSBtZXRyaWMgKGUuZyB0aGVyZSdzIGEgODgl IGNoYW5jZSB0aGF0IGZvby5jb20gaXMgdGhlIGF1dGhvcml6ZWQgRE5TIG5hbWUgZm9yICp0aGlz X2tleSkNCg0KSSBtYXkgYmUgbG9va2luZyBhdCB0aGUgYmFjayBlbmQgb2YgdGhlIGVsZXBoYW50 LCBidXQgdGVybXMgbGlrZSAicGlubmluZyIgYW5kIHN1Y2ggc2VlbSB3cm9uZy4gIFdpdGggYSAi a2V5IGNlbnRyaWMiIHZpZXcsIHRoZSBETlMgYWRkcmVzcyBvciBvdGhlciBpbmZvcm1hdGlvbiBh cmUgYXR0cmlidXRlcyB0aGF0IGNhbiBiZSBhc3NpZ25lZCB0byBhIGtleSB2ZXJzdXMgYSBuYW1l IGNlbnRyaWMgcGVyc3BlY3RpdmUgdGhhdCBoYXMgbXVsdGlwbGUga2V5cyBwZXIgbmFtZSBhbmQg bWF5IG5lZWQgcGlubmluZy4gIA0KDQpQYXVsDQoNCj4NCj5PZmZsaW5lLCBwZW9wbGUgdHJ1c3Qg ZGlmZmVyZW50IHRoaW5ncy4gIFdvdWxkIHRoZXJlIGJlIGENCj5wcm90b2NvbC9zdGFuZGFyZC9t ZXRob2QgdG8gbW9kZWwgdGhpcyBpbiBhIG1vcmUgc2NhbGFibGUgd2F5IG9ubGluZSwgc28NCj5t dWNoIGJldHRlciwgSSB0aGluay4NCj4NCj5CZXN0LA0KPk1hcnRpbg0KDQoNCg== From jon@callas.org Wed Feb 1 17:45:50 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0FA11E815B for ; Wed, 1 Feb 2012 17:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71kSgQxhhLo6 for ; Wed, 1 Feb 2012 17:45:50 -0800 (PST) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 015DF11E80B0 for ; Wed, 1 Feb 2012 17:45:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 28B3131E087 for ; Wed, 1 Feb 2012 17:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMoM8VlFSFM4 for ; Wed, 1 Feb 2012 17:45:48 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id EDCF131E077 for ; Wed, 1 Feb 2012 17:45:47 -0800 (PST) Received: from [10.0.23.88] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Wed, 01 Feb 2012 17:45:48 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 01 Feb 2012 17:45:48 -0800 Mime-Version: 1.0 (Apple Message framework v1251.1) From: Jon Callas In-Reply-To: Date: Wed, 1 Feb 2012 17:45:46 -0800 Message-Id: References: <62F4ED71-4893-458D-B2F1-0651D85ACE3A@bbn.com> <4F21B25C.7070406@fifthhorseman.net> <20120126210653.GU16280@mail.yitter.info> <84A92419-9A72-41FA-BDD8-4E096EC5A952@virtualized.org> <14A0F2F6-E953-4C32-848F-22DEDB0A60A0@bbn.com> <686A6224-3CB0-4BD8-8E32-9389689EC7E6@callas.org> <000401cce0ff$8528aee0$8f7a0ca0$@hardjono.net> To: therightkey@ietf.org X-Mailer: Apple Mail (2.1251.1) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 01:45:50 -0000 On Feb 1, 2012, at 10:43 AM, Phillip Hallam-Baker wrote: > That is a good point, and one that threatens to create a whole new = chapter. >=20 >=20 > First, replying to Jon, what we are managing is not risk itself but > the cost imposed by the possibility of unintended outcomes. If the guy > is jumping out of a skyscraper and does not intend to make himself > into people pancake on the pavement, then he has a 100% probability of > realizing a major unintended outcome. >=20 > We could maybe come up with a precise term but the key point is that > the objective is to minimize the costs imposed by the unintended > outcomes. That is the way the system was originally designed and it is > still the right way to design the system. >=20 > What has changed is that a hundred million people now carry mobiles > with cameras and so suddenly the dwindling number of dictatorships are > discovering that they are now accountable for every atrocity their > security forces commit on camera. Phill, this is a great answer. I'll claim that it's just not the right = question. The Right Key has nothing to do with safe user experiences. Marginally, = we could address the sort of question such as "what does the SSL lock = *mean*?" but even that's pretty ill-defined. It also goes beyond whether = trustworthiness (whatever it means) is within scope. I still claim that we should not go near trustworthiness because I'd = rather come up with one good solution than several vague ones. The PKI = debates of fifteen years ago bit off more than they could chew, and = that's part of why we're here. I think we need to do less before we do = more. Jon From dkg@fifthhorseman.net Thu Feb 2 07:23:26 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DAF21F8587 for ; Thu, 2 Feb 2012 07:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65l7k7+BEVWz for ; Thu, 2 Feb 2012 07:23:25 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1897221F8585 for ; Thu, 2 Feb 2012 07:23:25 -0800 (PST) Received: from [192.168.13.75] (finestructure.net [108.58.6.99]) by che.mayfirst.org (Postfix) with ESMTPSA id 3EC72F970 for ; Thu, 2 Feb 2012 10:23:19 -0500 (EST) Message-ID: <4F2AAA82.7020109@fifthhorseman.net> Date: Thu, 02 Feb 2012 10:23:46 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20120125 Icedove/9.0.1 MIME-Version: 1.0 To: therightkey@ietf.org References: <62F4ED71-4893-458D-B2F1-0651D85ACE3A@bbn.com> <4F21B25C.7070406@fifthhorseman.net> <20120126210653.GU16280@mail.yitter.info> <84A92419-9A72-41FA-BDD8-4E096EC5A952@virtualized.org> <14A0F2F6-E953-4C32-848F-22DEDB0A60A0@bbn.com> <7BAC95F5A7E67643AAFB2C31BEE662D015676432E0@SC-VEXCH2.marvell.com> <1328062540.6161.116.camel@davinci.millnert.se> <7BAC95F5A7E67643AAFB2C31BEE662D01567643621@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567643621@SC-VEXCH2.marvell.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: therightkey@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 15:23:26 -0000 On 02/01/2012 08:20 PM, Paul Lambert wrote: > I may be looking at the back end of the elephant, but terms like "pinning" and such seem wrong. With a "key centric" view, the DNS address or other information are attributes that can be assigned to a key versus a name centric perspective that has multiple keys per name and may need pinning. Maybe i'm misunderstanding what you're saying here, but the main "key pinning" proposal seems name-centric to me, not key-centric. It's a way for a peer with a name you've already authenticated some other way to make assertions about what keys it will use to identify itself in the future. So it's focused on the persistence of the peer's name, and keys are just a mechanism to demonstrate that persistence. I think that's a good thing. Are you seeing it some other way? --dkg From dkg@fifthhorseman.net Thu Feb 2 11:44:18 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0F121F85E1 for ; Thu, 2 Feb 2012 11:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4juyJPG7F5sP for ; Thu, 2 Feb 2012 11:44:17 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8A51A21F85D4 for ; Thu, 2 Feb 2012 11:44:17 -0800 (PST) Received: from [192.168.13.75] (finestructure.net [108.58.6.99]) by che.mayfirst.org (Postfix) with ESMTPSA id 24324F970 for ; Thu, 2 Feb 2012 14:44:14 -0500 (EST) Message-ID: <4F2AE7AA.8050204@fifthhorseman.net> Date: Thu, 02 Feb 2012 14:44:42 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20120125 Icedove/9.0.1 MIME-Version: 1.0 To: therightkey@ietf.org References: <62F4ED71-4893-458D-B2F1-0651D85ACE3A@bbn.com> <4F21B25C.7070406@fifthhorseman.net> <20120126210653.GU16280@mail.yitter.info> <84A92419-9A72-41FA-BDD8-4E096EC5A952@virtualized.org> <14A0F2F6-E953-4C32-848F-22DEDB0A60A0@bbn.com> <686A6224-3CB0-4BD8-8E32-9389689EC7E6@callas.org> <000401cce0ff$8528aee0$8f7a0ca0$@hardjono.net> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [therightkey] trustworthiness [was: Re: Will the real RPF please stand up?] X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: therightkey@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 19:44:18 -0000 On 02/01/2012 08:45 PM, Jon Callas wrote: > I still claim that we should not go near trustworthiness because I'd rather come up with one good solution than several vague ones. The PKI debates of fifteen years ago bit off more than they could chew, and that's part of why we're here. I think we need to do less before we do more. I think there's an underlying tension in this discussion between two ways of seeing what we're trying to do: 0) we're trying to build one global mechanism for peer authentication that will work automatically for everyone, without any per-user adjustment Vs. 1) we're trying to build mechanisms for peer authentication that will allow tools to reflect the decisions and perceptions of trustworthiness made by their users (0) seems kind of like the holy grail most folks would like to see, and it would be very cool if things could Just Work like that. But i think it's a dangerous goal. It's dangerous because (0) seems to imply that all users face the same threats, have the same levels of acceptable risk, and share the same interests. This just isn't true in the real world, even in the limited domain of verification of identity assertions. If i'm an agent of the Central Council of Orgoreyn, i will be willing to accept different assertions of identity than if i work for the Imperial Court in Karhide. I may even have special access to to some identity certification material that my counterpart in Karhide does not (and vice versa). And if i'm an independent agent, unaligned (and potentially in conflict) with both regimes, then my assessment of any particular claim of identity will be different still. Designing a system that assumes all users will be willing to accept a single global identity authority (or set of identity authorities) without any reflection of the user's particular circumstances is a mistake. In particular, it seems likely to make the system be unreliable for people who are already marginalized, or for people who are in opposition to powers who have some control over the global identity authorities. So that leaves us with option (1), which has the sticky issue of needing to gather these personal/idiosyncratic requirements from users and interpret them into some sort of coherent technical policy. I know we can't solve those UI issues on this list, but i'd hope that any proposed solutions will at least consider the need to adjust for the user's circumstances and propose some kind of reasonably coherent policy approach to account for those circumstances. --dkg From hallam@gmail.com Thu Feb 2 12:50:33 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B381F21F857F for ; Thu, 2 Feb 2012 12:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.318 X-Spam-Level: X-Spam-Status: No, score=-3.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qV7AX9wLGP36 for ; Thu, 2 Feb 2012 12:50:33 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEE9A21F85BE for ; Thu, 2 Feb 2012 12:50:29 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3986073obb.31 for ; Thu, 02 Feb 2012 12:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=HjB7rKn6uWJ3iiQ6Eo4QVBlz8fQLUi4H/+4f0gUZFbw=; b=iSM2X6awY8xNdyjGBFyrtublvI2Gm5SfVgmtSMDG5JMpvPjbg6l+Y2lfFD5rejT14l /UHcFQ6GrFdIPFkdAejdTw2UG2QXEhnDczo3a/9+lFt+CgGIqZQyeQv+lTUSOaXWNBkv hjFG7Y89gRlcuTo4Ek3FKRpOA/PwlzaGc7v9I= MIME-Version: 1.0 Received: by 10.182.41.36 with SMTP id c4mr3995907obl.21.1328215829086; Thu, 02 Feb 2012 12:50:29 -0800 (PST) Received: by 10.182.208.7 with HTTP; Thu, 2 Feb 2012 12:50:29 -0800 (PST) In-Reply-To: <4F2AE7AA.8050204@fifthhorseman.net> References: <62F4ED71-4893-458D-B2F1-0651D85ACE3A@bbn.com> <4F21B25C.7070406@fifthhorseman.net> <20120126210653.GU16280@mail.yitter.info> <84A92419-9A72-41FA-BDD8-4E096EC5A952@virtualized.org> <14A0F2F6-E953-4C32-848F-22DEDB0A60A0@bbn.com> <686A6224-3CB0-4BD8-8E32-9389689EC7E6@callas.org> <000401cce0ff$8528aee0$8f7a0ca0$@hardjono.net> <4F2AE7AA.8050204@fifthhorseman.net> Date: Thu, 2 Feb 2012 15:50:29 -0500 Message-ID: From: Phillip Hallam-Baker To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [therightkey] trustworthiness [was: Re: Will the real RPF please stand up?] X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 20:50:33 -0000 This is one of the main points I make in the papers: Trustworthiness is always with respect to a specific set of risks. The risks faced by an elderly grandmother surfing the Internet to buy knitting supplies are very different to the risks faced by an opposition member in Iran. We are never going to achieve perfect security for either our users or ourselves. On Thu, Feb 2, 2012 at 2:44 PM, Daniel Kahn Gillmor wrote: > On 02/01/2012 08:45 PM, Jon Callas wrote: >> I still claim that we should not go near trustworthiness because I'd rat= her come up with one good solution than several vague ones. The PKI debates= of fifteen years ago bit off more than they could chew, and that's part of= why we're here. I think we need to do less before we do more. > > I think there's an underlying tension in this discussion between two > ways of seeing what we're trying to do: > > =A00) we're trying to build one global mechanism for peer authentication > that will work automatically for everyone, without any per-user adjustmen= t > > =A0Vs. > > =A01) we're trying to build mechanisms for peer authentication that will > allow tools to reflect the decisions and perceptions of trustworthiness > made by their users > > > (0) seems kind of like the holy grail most folks would like to see, and > it would be very cool if things could Just Work like that. =A0But i think > it's a dangerous goal. > > It's dangerous because (0) seems to imply that all users face the same > threats, have the same levels of acceptable risk, and share the same > interests. =A0This just isn't true in the real world, even in the limited > domain of verification of identity assertions. > > If i'm an agent of the Central Council of Orgoreyn, i will be willing to > accept different assertions of identity than if i work for the Imperial > Court in Karhide. =A0I may even have special access to to some identity > certification material that my counterpart in Karhide does not (and vice > versa). =A0And if i'm an independent agent, unaligned (and potentially in > conflict) with both regimes, then my assessment of any particular claim > of identity will be different still. > > Designing a system that assumes all users will be willing to accept a > single global identity authority (or set of identity authorities) > without any reflection of the user's particular circumstances is a > mistake. =A0In particular, it seems likely to make the system be > unreliable for people who are already marginalized, or for people who > are in opposition to powers who have some control over the global > identity authorities. > > So that leaves us with option (1), which has the sticky issue of needing > to gather these personal/idiosyncratic requirements from users and > interpret them into some sort of coherent technical policy. =A0I know we > can't solve those UI issues on this list, but i'd hope that any proposed > solutions will at least consider the need to adjust for the user's > circumstances and propose some kind of reasonably coherent policy > approach to account for those circumstances. > > =A0 =A0 =A0 =A0--dkg > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --=20 Website: http://hallambaker.com/ From jon@callas.org Thu Feb 2 13:25:53 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8925D21F8670 for ; Thu, 2 Feb 2012 13:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQpeluh7fDFL for ; Thu, 2 Feb 2012 13:25:53 -0800 (PST) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACDD21F8585 for ; Thu, 2 Feb 2012 13:25:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id A067A330253; Thu, 2 Feb 2012 13:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpFMtuxuL9kj; Thu, 2 Feb 2012 13:25:50 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 2EFBC33022B; Thu, 2 Feb 2012 13:25:50 -0800 (PST) Received: from [10.0.23.15] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Thu, 02 Feb 2012 13:25:50 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 02 Feb 2012 13:25:50 -0800 Mime-Version: 1.0 (Apple Message framework v1257) From: Jon Callas In-Reply-To: Date: Thu, 2 Feb 2012 13:25:47 -0800 Message-Id: <88E8EB1E-6702-4E93-934C-CD9731FC8F91@callas.org> References: <62F4ED71-4893-458D-B2F1-0651D85ACE3A@bbn.com> <4F21B25C.7070406@fifthhorseman.net> <20120126210653.GU16280@mail.yitter.info> <84A92419-9A72-41FA-BDD8-4E096EC5A952@virtualized.org> <14A0F2F6-E953-4C32-848F-22DEDB0A60A0@bbn.com> <686A6224-3CB0-4BD8-8E32-9389689EC7E6@callas.org> <000401cce0ff$8528aee0$8f7a0ca0$@hardjono.net> <4F2AE7AA.8050204@fifthhorseman.net> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1257) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org, Jon Callas Subject: Re: [therightkey] trustworthiness [was: Re: Will the real RPF please stand up?] X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 21:25:53 -0000 On Feb 2, 2012, at 12:50 PM, Phillip Hallam-Baker wrote: > This is one of the main points I make in the papers: Trustworthiness > is always with respect to a specific set of risks. The risks faced by > an elderly grandmother surfing the Internet to buy knitting supplies > are very different to the risks faced by an opposition member in Iran. > > > We are never going to achieve perfect security for either our users or > ourselves. Which is why we should stick to mechanism over policy. Jon From dkg@fifthhorseman.net Thu Feb 2 14:21:15 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0CC21F869F for ; Thu, 2 Feb 2012 14:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kqzrU+qhiR8 for ; Thu, 2 Feb 2012 14:21:14 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A74BF21F865B for ; Thu, 2 Feb 2012 14:21:14 -0800 (PST) Received: from [192.168.13.75] (finestructure.net [108.58.6.99]) by che.mayfirst.org (Postfix) with ESMTPSA id 6460CF970 for ; Thu, 2 Feb 2012 17:21:13 -0500 (EST) Message-ID: <4F2B0C74.7040205@fifthhorseman.net> Date: Thu, 02 Feb 2012 17:21:40 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20120125 Icedove/9.0.1 MIME-Version: 1.0 To: therightkey@ietf.org References: <20120126210653.GU16280@mail.yitter.info> <84A92419-9A72-41FA-BDD8-4E096EC5A952@virtualized.org> <14A0F2F6-E953-4C32-848F-22DEDB0A60A0@bbn.com> <686A6224-3CB0-4BD8-8E32-9389689EC7E6@callas.org> <000401cce0ff$8528aee0$8f7a0ca0$@hardjono.net> <4F2AE7AA.8050204@fifthhorseman.net> <88E8EB1E-6702-4E93-934C-CD9731FC8F91@callas.or g> In-Reply-To: <88E8EB1E-6702-4E93-934C-CD9731FC8F91@callas.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] trustworthiness [was: Re: Will the real RPF please stand up?] X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: therightkey@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 22:21:15 -0000 [quoting from two separate e-mails] dkg wrote: > So that leaves us with option (1), which has the sticky issue of needing > to gather these personal/idiosyncratic requirements from users and > interpret them into some sort of coherent technical policy. I know we > can't solve those UI issues on this list, but i'd hope that any proposed > solutions will at least consider the need to adjust for the user's > circumstances and propose some kind of reasonably coherent policy > approach to account for those circumstances. On 02/02/2012 04:25 PM, Jon Callas wrote: > > On Feb 2, 2012, at 12:50 PM, Phillip Hallam-Baker wrote: > >> We are never going to achieve perfect security for either our users or >> ourselves. > > Which is why we should stick to mechanism over policy. I think i'm in agreement with you here, Jon, and i hope i haven't confused the matter by my use of the word "policy" in the above paragraph. I'd appreciate clarification if you think i'm misunderstanding. The mechanism(s) we build need to be capable of implementing the user's policies, as expressed in some coherent (and hopefully comprehensible) way. But in designing these systems, we should not presume to set policy for all users. Choice of mechanism seems likely to affect the range of possible supported policies, though (e.g. if presenting a single, standard X.509 certificate is the only mechanism a server has to introduce itself, there's no way to express or implement a client's policy that requires corroboration from independent parties). So i don't think we can fully avoid discussion of policy, if only to trot out example policies to see if a proposed mechanism can support them. Regards, --dkg From hallam@gmail.com Thu Feb 2 15:00:47 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA4B21F8671 for ; Thu, 2 Feb 2012 15:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4Se3CyrfUJZ for ; Thu, 2 Feb 2012 15:00:46 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4899121F8670 for ; Thu, 2 Feb 2012 15:00:46 -0800 (PST) Received: by obbwd15 with SMTP id wd15so4148537obb.31 for ; Thu, 02 Feb 2012 15:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=nMpoZj5/5ISgbdwDW/u8ooFUBUbLE3DaEEB0zlUXsAY=; b=s2FbpoG2O0Ue4a3YDbHNPOjS7UgCfr154cOs20JYgX9puBwGXlTLiYQMQdPpNNBcSO 1EFlo1LLgt43Xq154Wze7Ig5TeHZnwiBVOclzXacls0qkFHP3iGpOod5Yvaqac56eRrU 6DfdmSntA8U4OZGoDrxNGGZsU+u6Pi15c+KWw= MIME-Version: 1.0 Received: by 10.182.115.99 with SMTP id jn3mr4381180obb.11.1328223645892; Thu, 02 Feb 2012 15:00:45 -0800 (PST) Received: by 10.182.208.7 with HTTP; Thu, 2 Feb 2012 15:00:45 -0800 (PST) In-Reply-To: <4F2B0C74.7040205@fifthhorseman.net> References: <20120126210653.GU16280@mail.yitter.info> <84A92419-9A72-41FA-BDD8-4E096EC5A952@virtualized.org> <14A0F2F6-E953-4C32-848F-22DEDB0A60A0@bbn.com> <686A6224-3CB0-4BD8-8E32-9389689EC7E6@callas.org> <000401cce0ff$8528aee0$8f7a0ca0$@hardjono.net> <4F2AE7AA.8050204@fifthhorseman.net> <88E8EB1E-6702-4E93-934C-CD9731FC8F91@callas.org> <4F2B0C74.7040205@fifthhorseman.net> Date: Thu, 2 Feb 2012 18:00:45 -0500 Message-ID: From: Phillip Hallam-Baker To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [therightkey] trustworthiness [was: Re: Will the real RPF please stand up?] X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 23:00:47 -0000 I am not at all keen on languages for describing how to analyze policy eith= er. So I don't think we can hope to develop a system that allows the user to define their own policy. Even trying to do that client side is likely to fail. So I see two options. Either the user trusts the browser provider to choose the right policy for them or they choose some agent to act on their behalf. The user can choose between trustycorp red label and trustycorp black label security policies. But micromanaging when a cert is to be accepted or not is not going to work. The other side of security policy I can see working is when a site makes a statement 'this is how our security configuration should look'. Now such a statement is not necessarily going to be an infalible indicator that a policy violation is some sort of attack, see DKIM. But just as DKIM records are useful to spam management companies, security policy statements do have some use. On Thu, Feb 2, 2012 at 5:21 PM, Daniel Kahn Gillmor wrote: > [quoting from two separate e-mails] > > dkg wrote: > >> So that leaves us with option (1), which has the sticky issue of needing >> to gather these personal/idiosyncratic requirements from users and >> interpret them into some sort of coherent technical policy. =A0I know we >> can't solve those UI issues on this list, but i'd hope that any proposed >> solutions will at least consider the need to adjust for the user's >> circumstances and propose some kind of reasonably coherent policy >> approach to account for those circumstances. > > > On 02/02/2012 04:25 PM, Jon Callas wrote: >> >> On Feb 2, 2012, at 12:50 PM, Phillip Hallam-Baker wrote: >> >>> We are never going to achieve perfect security for either our users or >>> ourselves. >> >> Which is why we should stick to mechanism over policy. > > I think i'm in agreement with you here, Jon, and i hope i haven't > confused the matter by my use of the word "policy" in the above > paragraph. =A0I'd appreciate clarification if you think i'm misunderstand= ing. > > The mechanism(s) we build need to be capable of implementing the user's > policies, as expressed in some coherent (and hopefully comprehensible) > way. =A0But in designing these systems, we should not presume to set > policy for all users. > > Choice of mechanism seems likely to affect the range of possible > supported policies, though (e.g. if presenting a single, standard X.509 > certificate is the only mechanism a server has to introduce itself, > there's no way to express or implement a client's policy that requires > corroboration from independent parties). =A0So i don't think we can fully > avoid discussion of policy, if only to trot out example policies to see > if a proposed mechanism can support them. > > Regards, > > =A0 =A0 =A0 =A0--dkg > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --=20 Website: http://hallambaker.com/ From aerowolf@gmail.com Sat Feb 4 13:45:34 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF3C21F8476 for ; Sat, 4 Feb 2012 13:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.138 X-Spam-Level: X-Spam-Status: No, score=-0.138 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_50=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyRSZjpdAFpB for ; Sat, 4 Feb 2012 13:45:33 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFA8A21F8475 for ; Sat, 4 Feb 2012 13:45:33 -0800 (PST) Received: by dakl33 with SMTP id l33so4377148dak.31 for ; Sat, 04 Feb 2012 13:45:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:mime-version:content-type; bh=bodzcnciH1j/UpowWFmcRzOBwixTAl/fQ2lWvGb5850=; b=JfTF8+pAzWRktvO1xlJNGO5KP9No0uGmePekVVdPWInuMLovY7hQlzWjf6XXQyI9zy KuFxpqFXKZzOPAAOb4jM0vS9fLZgRJOpTVSH3EyhksRGpOUDftwuFyLFak1urnvxH3Sc HXz4u+UWMFaexAVzpBaTN0JdDIS78GfYAQYvI= Received: by 10.68.73.105 with SMTP id k9mr29781044pbv.121.1328391933627; Sat, 04 Feb 2012 13:45:33 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id kx17sm24738580pbb.19.2012.02.04.13.45.30 (version=SSLv3 cipher=OTHER); Sat, 04 Feb 2012 13:45:32 -0800 (PST) From: "Kyle Hamilton" To: "Phillip Hallam-Baker" Date: Sat, 4 Feb 2012 13:45:38 -0800 (Pacific Standard Time) Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgy969fhhfbo32qqjqd2 Cc: therightkey@ietf.org Subject: Re: [therightkey] Why the focus on The? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 21:45:34 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgy969fhhfbo32qqjqd2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=us-ascii DQpPbiBGcmksIEphbiAyNywgMjAxMiBhdCA4OjEwIFBNLCBQaGlsbGlwIEhhbGxhbS1CYWtlciA8 aGFsbGFtQGdtYWlsLmNvbT4gd3JvdGU6DQo+IEkgdGhpbmsgd2Ugc2hvdWxkIGZvY3VzIG9uIGlk ZW50aWZ5aW5nIHByb2JsZW1zIGF0IHRoaXMgc3RhZ2UuDQoNCkkgYWdyZWUuICANCg0KMSkgV2Ug bmVlZCB0byBmaWd1cmUgb3V0IHdoYXQgd2UncmUgcmVhbGx5IHRyeWluZyB0byBkby4gIEkgdGhp bmsgaXQncyBhbiBhdHRlbXB0IHRvIGltcHJvdmUgdGhlIGRldGVjdGlvbiByYXRlIG9mIGltcGVy c29uYXRpb24gZnJhdWQsIGluIGFuIGF0dGVtcHQgdG8gcmVkdWNlIHRoZSBsaWtlbGlob29kIHRo YXQgSiBSYW5kb20gVXNlciB3aWxsIGJlIGNvZXJjZWQgb3Igc2VkdWNlZCBpbnRvIGludGVyYWN0 aW5nIGNvbmZpZGVudGlhbGx5IHdpdGggc29tZW9uZSBoZSB0aGlua3MgaXMgc29tZW9uZSBlbHNl LCBvciBoYXMgYSByZXB1dGF0aW9uIG90aGVyIHRoYW4gd2hhdCBoZSBwZXJjZWl2ZXMuDQoNCjIp IFdlIG5lZWQgdG8gZGV2ZWxvcCBhIGZsZXhpYmxlLCB1c2VmdWwgcmlzayBtb2RlbCBzbyB0aGF0 IHdlIGtub3cgd2hhdCBvdXIgd29yayBzdXBwb3J0cy4NCg0KMykgUEtJWCBhbmQgZXZlcnlvbmUg aW52b2x2ZWQgaGFzIGJlZW4gc28gaW50ZXJlc3RlZCBpbiBnZXR0aW5nIHRoZSBzaW5ndWxhciBj b3JyZWN0IHRoYXQgdGhleSd2ZSBjb21wbGV0ZWx5IGxvc3Qgc2lnaHQgb2YgdGhlIHBvc3NpYmls aXR5IG9mIHRoZSBwbHVyYWwuICBFdmVyeSBzdGFuZGFyZCBpcyBkZXNpZ25lZCB0byBkbyBvbmUg dGhpbmcgYXMgYmVzdCBhcyB0aGUgZGVzaWduZXJzIGNhbiwgYnV0IHdpdGhvdXQgYW55IG92ZXJh cmNoaW5nIHNjaGVtYSBvciBkZXNpZ24gdG8gcHVsbCBldmVyeXRoaW5nIHRvZ2V0aGVyLCBhbmQg d2l0aG91dCBhbnkgdGhvdWdodCBnaXZlbiB0byB0aGUgaW5ldml0YWJsZSBkZW1hbmQgZm9yIHJl ZHVuZGFuY3kuDQoNCjQpIEV2ZXJ5IGNsaWVudCBwcm90b2NvbCBtdXN0IHBhdGNoIGFyb3VuZCBQ S0lYJ3MgaW5hYmlsaXR5L3Vud2lsbGluZ25lc3MgdG8gY29ubmVjdCBpdHMgcGFydHMuICBUTFMg aXMgYSBwcmltZSBleGFtcGxlOiBPQ1NQIFN0YXBsaW5nIHBhdGNoZXMgdGhlIGxhY2sgb2YgY29u bmVjdGlvbiBiZXR3ZWVuIENlcnRpZmljYXRlIGFuZCB0aGUgY3JlZGVudGlhbHMgd2hpY2ggc3Rh dGUgdGhhdCB0aGUgQ2VydGlmaWNhdGUgcmVhbGx5IGlzIGN1cnJlbnRseSB2YWxpZC4gIFNlY3Vy ZSBSZW5lZ290aWF0aW9uIHBhdGNoZXMgdGhlIGxhY2sgb2YgdXNlZnVsLCBlZmZlY3RpdmUsIGFu ZCB1c2VyLWFjY2VwdGFibGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiAgT0NTUCBTdGFwbGluZyB3 b3VsZCBub3QgbmVlZCB0byBleGlzdCBpZiB0aGVyZSBoYWQgYmVlbiBhIHNpbmdsZSBwb3J0YWJs ZSBmb3JtYXQgdG8gcGFzcyBhcm91bmQgdGhlIGVudGlyZSBzZXQgb2YgYXV0aGVudGljYXRvcnMu ICBTZWN1cmUgUmVuZWdvdGlhdGlvbiB3b3VsZCBub3QgbmVlZCB0byBleGlzdCBpZiB0aGUgbWFp biBjb25jZXJucyBwcmV2ZW50aW5nIHVzZXIgKG11Y2ggbGVzcyBhZG1pbi9kZXZlbG9wZXIhKSBh Y2NlcHRhYmlsaXR5IG9mIGNsaWVudCBhdXRoZW50aWNhdGlvbiBoYWQgYmVlbiBhZGRyZXNzZWQu ICAoSW5mb3JtYXRpb24gbGVha2FnZSwgZGF0YWJhc2UgbWF0Y2hpbmcsIGFuZCBwcm9taXNjdW91 cyBhZHZlcnRpc2VtZW50IG9mIHRoZSBpZGVudGl0aWVzIG9mIHRoZSBlbmRwb2ludHMgaGF2ZSBi ZWVuIGNpdGVkLCB3ZXJlIGNpdGVkIGEgZGVjYWRlIGFnbyBldmVuLCBidXQgbm9ib2R5IGZpeGVk IHRoZW0uICBUaGUgaWRlYSBvZiBhIHVzZXIncyBjb21wdXRlciBiZWluZyB0aGUgc2FtZSBsb2dp Y2FsIGVudGl0eSBhcyB0aGUgdXNlciBoaW1zZWxmIGJyZWFrcyB1bmRlciB0aGUgaGFyc2ggZ2xh cmUgb2YgcmVhbGl0eTogYSB1c2VyJ3MgY3JlZGVudGlhbHMgYXJlIG9mdGVuIHVzZWQgZm9yIHRo aW5ncyBvZiB3aGljaCB0aGUgdXNlciBoYXMgbm8ga25vd2xlZGdlIGFuZCBmb3Igd2hpY2ggdGhl IHVzZXIgbmV2ZXIgZ2F2ZSBjb25zZW50LiAgSSB0aGluayB3ZSBuZWVkIGEgY29tYmluYXRpb24g dXNlci9hcHBsaWNhdGlvbiBpZGVudGlmaWVyLCBhIGtpbmQgb2Ygb3ZlcmFyY2hpbmcgdXNlciBp ZGVudGlmaWVyIHJ1bm5pbmcgaW5kaXZpZHVhbCBhcHBsaWNhdGlvbnMgdW5kZXIgdGhlaXIgb3du IHVzZXJJRHMuICBUaGlzIHdvdWxkIHBlcm1pdCBmaW5lci1ncmFpbmVkIGNvbnRyb2wgdGhhbiBz aW1wbHkgdGhlIHVzZXIncyBsb2dpbiBzZXNzaW9uLikNCg0KNSkgRXZlcnkgY2xpZW50IGRldmVs b3BlciBiZWxpZXZlcyB0aGF0IHRoZSBjdXJyZW50IHN0YW5kYXJkcywgaW1wbGVtZW50YXRpb25z IGFuZCBkZXNpZ25zIGNvbXByaXNlIG5vdCBvbmx5IHRoZSBleGlzdGluZyBidXQgYWxzbyB0aGUg b25seSBwb3NzaWJsZSBsYW5kc2NhcGUsIGFuZCBpbm5vdmF0aW9uIGlzIHN0aWZsZWQgd2l0aGlu IHRoZSBzdGFuZGFyZHMgYm9kaWVzIHRoZW1zZWx2ZXMuICBUaGlzIGxlYWRzIHRvIG1hc3NpdmUg ZnJhZ21lbnRhdGlvbiBvZiB0aGUgbWFya2V0IHdoZW4gZGlmZmVyZW50IGNvbmNlcm5zIHRha2Ug dGhlaXIgY3VlcyBmcm9tIGV4aXN0aW5nIHN0YW5kYXJkcyB0byBkbyB0aGUgYmVzdCB0aGV5IGNh biB0byBzZXJ2ZSB0aGVpciBvd24gbmVlZHMgYW5kIHNlbWFudGljcyBhcyBUaGUgT25lIFRydWUg V2F5LiAgVGhlcmUgYXJlIG5vIHRydWx5IGZsZXhpYmxlLCB0cnVseSBleHRlbnNpYmxlIHNvbHV0 aW9ucyB3aGljaCBsZXZlcmFnZSB0aGUgc3RyZW5ndGggb2YgdGhlIEFTTi4xIHBhcnNlci4NCg0K NikgV2UgbmVlZCBtb3JlIHRoYW4ganVzdCBhIHNpbmdsZSBrZXkgYW5kIHByb29mIGR1cmluZyBo YW5kc2hha2UuICBXZSBuZWVkIG11bHRpcGxlIGF1dGhvcml0eSBjaGFpbnMsIGZvciBtdWx0aXBs ZSBhdXRob3JpdHkgdHJ1c3RzIG9mIG11bHRpcGxlIHR5cGVzLiAgV2UgbmVlZCBPQ1NQIHJlc3Bv bnNlcyBmb3IgdGhlbSwgd2UgbmVlZCB0aW1lc3RhbXBzLCB3ZSBuZWVkIHNpZ25hdHVyZXMsIHdl IG5lZWQgbG9uZy10ZXJtIGV2aWRlbmNlIG9mIGFjY2VwdGFiaWxpdHkgYXQgdGhlIG1vbWVudCBv ZiBldmFsdWF0aW9uLiAgQ291cnRzIGNhbiBzb2x2ZSB0aGUgZGlzcHV0ZXMgd2UgY2FuJ3QuICBX ZSBjYW4ndCBmaWdodCB0aGUgZXhpc3RlbmNlIG9mIGRpc3B1dGVzLiAgQWxsIHdlIGNhbiBkbyBp cyBvdXIgYmVzdCB0byBiZSBmbGV4aWJsZSBzbyB0aGF0IHdlIGNhbiBoZWxwIG91ciB1c2VycyBt ZWV0IHRoZWlyIGxlZ2FsIG9ibGlnYXRpb25zLCBzbyB0aGF0IHdlIGNhbiByZWR1Y2UgdGhlIGNv c3Qgb2YgbGl0aWdhdGlvbiwgc28gdGhhdCB3ZSBjYW4gcmVkdWNlIHRoZSB3b3JrbG9hZCBvbiB0 aGUganVkaWNpYXJ5LiAgKEkgc3BlYWsgb2YgdGhpcyBrbm93aW5nIG9ubHkgYWJvdXQgVVMgcmVx dWlyZW1lbnRzLCBJIHdpbGwgbm90IGNsYWltIHRvIGtub3cgYW55dGhpbmcgYWJvdXQgb3RoZXIg c3lzdGVtcy4pDQoNCjcpIFdlIG5lZWQgdG8gY3JlYXRlIHN0cm9uZ2VyIG1lYW5zIG9mIGlkZW50 aWZ5aW5nIGFuZCBhdXRoZW50aWNhdGluZyBjZXJ0aWZpY2F0ZXMsIHN1Y2ggdGhhdCB3ZSdyZSBu b3QgbGltaXRlZCBzb2xlbHkgdG8gdGhlIHNlcmlhbCBudW1iZXIgYW5kIGhhc2ggb2YgdGhlIERO IG9mIHRoZSBpc3N1ZXIuICBXZSBuZWVkIHRvIGhhdmUgYSBkcm9wLWluIHJlcGxhY2VtZW50IGZv ciB0aGUgY3VycmVudCBDUkwtZmVkIE9DU1AgcmVzcG9uZGVyIHdvcmtmbG93LCBwcmVmZXJhYmx5 IHN1Y2ggdGhhdCBleGlzdGluZyByZXNwb25kZXIgaW1wbGVtZW50YXRpb25zIHdvbid0IGNob2tl IHdoZW4gZmVkIGVuaGFuY2VkIENSTHMgd2l0aCBiZXR0ZXIgYXV0aGVudGljYXRpb24uICAoVGhl IGV4aXN0ZW5jZSBvZiB0aGF0IHdvcmtmbG93IGlzIHRoZSBtYWluIHJlYXNvbiBpdCBkb2Vzbid0 IG1ha2Ugc2Vuc2UgdG8gY3JlYXRlIHNvbWV0aGluZyBlbnRpcmVseSBuZXcsIGFuZCB3aHkgaXQg ZG9lcyBtYWtlIHNlbnNlIHRvIGNyZWF0ZSBDUkwgZXh0ZW5zaW9ucyB0byBjYXJyeSBzdHJvbmcg Y2VydCBhdXRoIGluZm9ybWF0aW9uLiAgU2VlIGRyYWZ0LWhhbWlsdG9uLWNybC13aGl0ZWxpc3Qt MDAgZm9yIGEgc3RhcnRpbmcgcG9pbnQuKQ0KDQo4KSBXZSBuZWVkIHRvIGNyZWF0ZSBzb21lIG1l YW5zIHRvIHBlcm1pdCBwZW9wbGUgKGluY2x1ZGluZyBjb3Jwb3JhdGUgcGVvcGxlIGFuZCBpbmRp dmlkdWFscykgdG8gaW1wbGVtZW50IHNhbmUgYW5kIGVmZmVjdGl2ZSBrZXkgbWFuYWdlbWVudCBw cm9jZWR1cmVzLiAgRm9yIGV4YW1wbGUsIHdoeSBkbyB3ZSBoYXZlIHRvIGhhdmUgaGlnaCB2YWx1 ZSBFViBjZXJ0aWZpZWQga2V5cyBvbiB0aGUgd2Vic2VydmVyPyAgV2h5IGNhbid0IHdlIGluY2x1 ZGUgbmFtZUNvbnN0cmFpbnRzIGluIGxlYWYgY2VydGlmaWNhdGVzLCBhbGxvd2luZyBwZW9wbGUg dG8gY2VydGlmeSB0aGVpciBvd24gd2Vic2VydmVyIGRldmljZSBrZXlzIHVuZGVyIHRoZWlyIGRl Y2xhcmVkIG93bmVyc2hpcD8gIChJIGtub3cgaXQncyBsZWdhY3ksIFguNTA5IGRlZmluZWQgaXQg YXMgb25seSBiZWluZyBhYmxlIHRvIG9jY3VyIHdpdGhpbiBDQSBjZXJ0aWZpY2F0ZXMgYW5kIFJG QzUyODAgaW5oZXJpdGVkIHRoYXQgbGFuZ3VhZ2UgZnJvbSBpdHMgYmFzZS4gIEdyYW50ZWQsIG5v Ym9keSBjb3VsZCBoYXZlIGZvcmVzZWVuIHRoZSBuZWVkLCBidXQgaXQncyBhIHJlc3RyaWN0aW9u IHRoYXQgcmVkdWNlcyB0aGUgYWdpbGl0eSBvZiB0aGUgc3lzdGVtLiAgSXQncyBhIHBvbGljeS1i YXNlZCBtYW5kYXRlIHRoYXQgaGFzIG5vIHBsYWNlIGluIGEgdGVjaG5pY2FsIHN0YW5kYXJkLikN Cg0KQW5kIG1vc3QgaW1wb3J0YW50bHkuLi4NCjkpIFdlIG11c3QgYWxsb3cgb3VyIHNhY3JlZCBj b3dzIHRvIGJlIHB1bmN0dXJlZC4gIE5vIGNsYXVzZSBpbiBhbnkgc3RhbmRhcmQgaGFzIGFueSBk aXZpbmUgcmlnaHQgb2YgZXhpc3RlbmNlLCBhbmQgd2UgbmVlZCB0byBkaXNjYXJkIHRoZSBjbGF1 c2VzIGFuZCBzZW1hbnRpY3MgaW4gZXZlcnkgc3RhbmRhcmQgd2hpY2ggcHJldmVudCBwbGF5aW5n IHdlbGwgd2l0aCBvdGhlcnMgaW4gb3VyIHdvcmxkIG9mIHdoYXQgYXJlIGVmZmVjdGl2ZWx5IDgr IGJpbGxpb24gc292ZXJlaWduIHN0YXRlcy4NCg0KU2VlLCBYLjUwOSB3YXMgZGV2ZWxvcGVkIGJ5 IElUVS1ULCBhbiBhcm0gb2YgVU4uICBUaGUgbWVtYmVycyBvZiBVTiBoYXZlIGNvbW1pdHRlZCB0 byBtaW5pbWl6aW5nIHRoZSBhZGRpdGlvbiBhbmQgcmVjb2duaXRpb24gb2YgbmV3IHNvdmVyZWln bnMsIGFuZCB0aGVyZSBhcmUgYXJvdW5kIDI1MCBpbmRpdmlkdWFsIG9uZXMgb24gdGhlIHdvcmxk IHN0YWdlLiAgSW4gYSBwb29sIHRoYXQgc21hbGwsIGl0IGlzIGp1c3QgYmFyZWx5IGZlYXNhYmxl IGZvciBldmVyeSBzb3ZlcmVpZ24gdG8gbWFpbnRhaW4gZGlwbG9tYXRpYyByZWxhdGlvbnMgd2l0 aCBldmVyeSBvdGhlci4gIChUaGUgaWRlYSBvZiAidGhlIHNvdmVyZWlnbiBzdGF0ZSIgaW1wbGll cyBhYnNvbHV0ZSBwb3dlciB0byBkbyB3aGF0ZXZlciBpdCB3YW50cyBpbiBpdHMgb3duIGludGVy bmFsIGFmZmFpcnMsIHdpdGhvdXQgYmVpbmcgaGVsZCB0byBhbnN3ZXIgYnkgYW55IHBlZXIgc3Rh dGUgaW4gYW55IG1lYW5pbmdmdWwgd2F5LikNCg0KTm93LCB3ZSBwZXJzb25hbGx5IGNhbm5vdCBo b2xkIGVhY2ggb3RoZXIgdG8gYW5zd2VyLiAgV2UgY2FuIHBldGl0aW9uIHRoZSBzdGF0ZSB0byBy ZXNvbHZlIGRpc3B1dGVzIGJldHdlZW4gdXMsIGFuZCB0aGUgc3RhdGUgY2FuIGhvbGQgdXMgdG8g YW5zd2VyIGluIHNvbWUgbWFubmVyLCBidXQgd2UgY2Fubm90IGluZGl2aWR1YWxseSBwZXJzb25h bGx5IHRha2UgbWF0dGVycyBpbnRvIG91ciBvd24gaGFuZHMgdG8gc2VpemUgcmVjb21wZW5zZSBm b3IgcGVyY2VpdmVkIHdyb25ncyBhZ2FpbnN0IHVzLiAgV2UgYXJlIChsZWdhbGx5LCBhdCBsZWFz dCkgaW1tdW5lIGZyb20gZGlyZWN0IG5vbi1wb2xpdGljYWwgaW50ZXJmZXJlbmNlIGJ5IG91ciBw ZWVycy4NCg0KSW4gYSB2ZXJ5IHJlYWwgc2Vuc2UsIGludGVyYWN0aW9ucyBiZXR3ZWVuIHBlb3Bs ZSAobmF0dXJhbCBhbmQgY29ycG9yYXRlIGJvdGgpIGFyZSBpbnRlcmFjdGlvbnMgYmV0d2VlbiBz b3ZlcmVpZ25zLCBhbGJlaXQgaW4gYSBsb3dlciBvcmRlci4gIFdoZW4gdGhlIGluZGl2aWR1YWwg Z29lcyBpbnRvIGJ1c2luZXNzLCBoZSBpcyBieSBkZWZhdWx0IGEgInNvbGUgcHJvcHJpZXRvciIs IGFuZCBwYXJ0aWNpcGF0ZXMgaW4gdGhlIG1hcmtldHBsYWNlIGFzIGEgbGVnYWwgcGVlciB0byB0 aGUgY29ycG9yYXRpb24uICBUaGUgaW5kaXZpZHVhbCBoYXMgbm8gcmlnaHQgdG8gZGVtYW5kIHRo YXQgYSBjb3Jwb3JhdGlvbiBvcGVuIGl0cyByZWNvcmRzIHRvIGhpbTsgdGhlIGNvcnBvcmF0aW9u IGVxdWFsbHkgaGFzIG5vIHJpZ2h0IHRvIGRlbWFuZCB0aGF0IGFueSBvdGhlciBwZXJzb24gb3Bl biBoaXMgcmVjb3JkcyB0byBpdC4gIEludGVybmFsIGFmZmFpcnMgYXJlIGludGVybmFsIGFmZmFp cnMsIGFuZCB0aGUgb25seSB3YXkgYW55dGhpbmcgZ2V0cyBkcmFnZ2VkIGludG8gcHVibGljIGxp Z2h0IGlzIGlmIGl0J3MgYnJvdWdodCB0byB0aGUgYXR0ZW50aW9uIG9mIHRoZSBzdGF0ZSBpbiBh IHdheSB0aGF0IHJlcXVpcmVzIGl0LCBvciBpZiBzb21lb25lIG1hbmFnZXMgdG8gbGVhcm4gYWJv dXQgaXQgYW5kIG1ha2UgaXQgcHVibGljLg0KDQpUaGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHBlcnNv bnMgYW5kIHN0YXRlcyBpcyB0aGF0IGEgc3RhdGUgZG9lc24ndCBhdXRvbWF0aWNhbGx5IGhhdmUg bGF3cyBpdCBjYW4gcGV0aXRpb24gZm9yIHJlZHJlc3MgdW5kZXIsIGl0IGNhbiBvbmx5IGZvcm0g dHJlYXRpZXMgYW5kIHRyeSB0byBqZWFsb3VzbHkgZ3VhcmQgaXRzIG93biBpbnRlcmVzdHMgZnJv bSBpbnRlcmZlcmVuY2UgYnkgb3RoZXIgc3RhdGVzLiAgSW4gdGhlIGxvd2VyIG9yZGVyIG9mIHBl cnNvbmFsIHNvdmVyZWlnbnR5LCB0aGUgc3RhdGUgcHJvdmlkZXMgYSBzb3J0IG9mICJkZWZhdWx0 IHRyZWF0eSIgdG8gaXRzIHBlcnNvbnMsIGFuZCBwcm92aWRlcyBhIHNlcnZpY2UgdG8gbm9udmlv bGVudGx5IHJlc29sdmUgZGlzcHV0ZXMgdW5kZXIgaXQuICAoYXQgbGVhc3QgaW4gZmlyc3Qgd29y bGQgY291bnRyaWVzLikNCg0KU29tZXRoaW5nIHRoYXQgYm90aCBpbmRpdmlkdWFscyBhbmQgc3Rh dGVzIGhhdmUgaXMgInJlcHV0YXRpb24iLiAgVGhlcmUgaXMgbm8gYmFyIHRvIHNvbWVvbmUgZWxz ZSBzYXlpbmcgc29tZXRoaW5nIGFib3V0IHlvdSBhbmQgeW91ciBpbnRlcmFjdGlvbnMgb3ZlciBh IHBlcmlvZCBvZiB0aW1lLCBhcyBsb25nIGFzIGl0J3MgdHJ1ZS4gIEEgY3JlZGl0IHJlcG9ydCBp cyBhIHN0YXRlbWVudCBvZiByZXB1dGF0aW9uLiAgWW91ciBzdGF0ZSBpZGVudGl0eSBpcyBvbmx5 IGFuIGluZGV4IHRvIHRoZSAoc3RhdGUtcmVndWxhdGVkKSByZXB1dGF0aW9uIHlvdSd2ZSBidWls dCB1cC4NCg0KVGhhdCB3YXMgYWxsIHRvIHByb3ZpZGUgY29udGV4dCBmb3IgdGhpcyBxdWVzdGlv bjogaWYgd2UncmUgZ29pbmcgdG8gZGVzaWduIHNvbWV0aGluZyBiYXNlZCBvbiBhIHRlY2hub2xv Z3kgZGVzaWduZWQgZm9yIHNvdmVyZWlnbnMsIGNhbiB3ZSBhdCBsZWFzdCBpbXBvcnQgdGhlIGNv cnJlY3Qgc2VtYW50aWNzIGluIHRoZSBjb3JyZWN0IHBsYWNlPw0KDQotS3lsZSBI --gmsm1.9.5eqgy969fhhfbo32qqjqd2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMDQyMTQ1MzhaMCMGCSqGSIb3DQEJBDEWBBRUX1Ycn2fV7MDajll1V42l SyfNozBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAljdWIw/JFv2S7ExhIERuFSIwAf3FT7clKZILSW3TNPxU4kE2zUxtkeT78PmULBCbbVe9 j8d70JCRQ35L1oVDVb3x8T889ygPgtHVWBccGHE5iGxejBIxmaQ6hKVVcSu8n2zvtILixbTS3Eji /2FyDbQEnB/V725qbgfMQBQGc4uRfLOXIeX9TbSF/HVAUand2jWDTB+tV/hdH/kwc7Wbw0QYMehW TbjKKqJ8YP3HZeTcBInwhhECYa9J6rLxT+BdSU75hrDJvke/EzZ7Jo3B14A/Kq4FNadVXGEnahV+ AaNS5zsRNe46tGJTx/r8CWdLZcA1CK1GDdPQhMJYbc4MYgAAAAAAAA== --gmsm1.9.5eqgy969fhhfbo32qqjqd2-- From aerowolf@gmail.com Sat Feb 4 15:27:10 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021BA21F8494 for ; Sat, 4 Feb 2012 15:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.215 X-Spam-Level: X-Spam-Status: No, score=-1.215 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKueDil7fIgl for ; Sat, 4 Feb 2012 15:27:09 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9E721F848B for ; Sat, 4 Feb 2012 15:27:09 -0800 (PST) Received: by dakl33 with SMTP id l33so4417510dak.31 for ; Sat, 04 Feb 2012 15:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:date:message-id:subject:in-reply-to:references:mime-version :content-type; bh=8Q+MzTaux2WaGXfXwXwhq6sSzfO8yQsOAqovuwquYfw=; b=kfXLx1u6ZQUHYabEqOueTZN+bI30K+iibl88S2Mk4ClNWiPMZ15LPYkKOTYnr2xz12 mfDdDPPBtHDEH35QcMHff9J6FiXyy8LS2cPJl9ZghZQ0y/s3aNwNkQJS/6JRMYWBi3c6 DDnMNx30DwZJkpAsr/1Ra+pplxpg6Ikda45cg= Received: by 10.68.227.71 with SMTP id ry7mr3580890pbc.114.1328398029296; Sat, 04 Feb 2012 15:27:09 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id p9sm25396454pbb.9.2012.02.04.15.27.06 (version=SSLv3 cipher=OTHER); Sat, 04 Feb 2012 15:27:07 -0800 (PST) From: "Kyle Hamilton" To: therightkey@ietf.org Date: Sat, 4 Feb 2012 15:27:13 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgy99w2ulu19ixfjzpm2 Subject: Re: [therightkey] Why the focus on The? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 23:27:10 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgy99w2ulu19ixfjzpm2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 DQoNCk9uIEZyaSwgSmFuIDI3LCAyMDEyIGF0IDE6MjYgUE0sIERhbmllbCBLYWhuIEdpbGxtb3Ig PGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD4gd3JvdGU6DQo+IE9uIDAxLzI3LzIwMTIgMDQ6MDIgUE0s IEt5bGUgSGFtaWx0b24gd3JvdGU6DQo+PiBXaHkgaXMgZXZlcnl0aGluZyBzbyBzaW5nbGUtcG9p bnQtb2YtZmFpbHVyZSBpbiB0aGUgU2VjdXJpdHkgd29ya2luZw0KPj4gYXJlYT8goERvZXMgaXQg cmVhbGx5IGhhdmUgdG8gYmU/DQo+DQo+IFlvdSBzZWVtIHRvIGJlIHN1Z2dlc3RpbmcgdGhhdCB3 ZSBzaG91bGQgYmUgY29uc2lkZXJpbmcgcmVkdW5kYW50LA0KPiBjb3Jyb2JvcmF0aXZlIGNlcnRp ZmljYXRpb24gdGVjaG5pcXVlcyB0byBlbnN1cmUgdGhhdCB0aGUga2V5IG9mZmVyZWQgYnkNCj4g dGhlIHBlZXIgcmVhbGx5IGRvZXMgYmVsb25nIHRvIHRoZSBwZWVyLg0KPg0KPiBJIGFncmVlIHRo YXQgYW55IHNvbHV0aW9uIHdoaWNoIGFjdHVhbGx5IGltcHJvdmVzIG9uIHRoZSBzdGF0dXMgcXVv IHdpbGwNCj4gaGF2ZSB0byBpbmNsdWRlIHRoaXMgc29ydCBvZiBhcHByb2FjaC4NCj4NCj4gSSBk b24ndCB0aGluayB0aGF0IGl0IGZvbGxvd3MgZnJvbSB0aGlzIHRoYXQgeW91J2QgbmVlZCB0byBl bmNvdXJhZ2UNCj4gcGVvcGxlIHRvIHVzZSBtdWx0aXBsZSBrZXlzIHBlciBlbnRpdHksIHRob3Vn aC4NCg0KSSBiZWxpZXZlIGl0J3MgaW1wb3J0YW50IHRvIGFwcHJvYWNoIHRoZSBwcm9ibGVtIGZy b20gdGhpcyB2YW50YWdlIGJlY2F1c2Ugd2UgbmVlZCB0byBlbnN1cmUgdGhhdCBrZXkgbWFuYWdl bWVudCBhbmQgcm9sbG92ZXIgY2FuIGJlIGVhc3kgYW5kIGhhc3NsZS1mcmVlLCB0aGUgc2FtZSB3 YXkgdGhhdCBETlMgdXBkYXRlcyBjYW4gYmUuDQoNCj4gVGhlIGJlc3QgYXJndW1lbnQgaSd2ZSBz ZWVuIGZvciB1c2luZyBtdWx0aXBsZSBrZXlzIGlzIHRoZSBtYXRlcmlhbA0KPiBDaHJpcyBQYWxt ZXIgKGkgdGhpbmspIHdyb3RlIGFib3V0IGhvdyB0byBkZXBsb3kgcHVibGljIGtleSBwaW5uaW5n LA0KPiB3aGVyZSBoYXZpbmcgYSAocHJlc3VtYWJseSBvZmZsaW5lKSBiYWNrdXAga2V5IHBlciBt YW5hZ2VkIGVudGl0eSBnaXZlcw0KPiB5b3Ugc29tZSBmbGV4aWJpbGl0eSBpZiB5b3UgZGlzY292 ZXIgYSBjb21wcm9taXNlIG9mIHBpbm5lZCBrZXkgbWF0ZXJpYWwNCj4gdGhhdCdzIGN1cnJlbnRs eSBpbiB1c2UuDQoNCkNvbXByb21pc2UgKG4pOiBBbnkgcmVkdWN0aW9uIGluIHRoZSB1dGlsaXR5 IG9mIGEgcHVibGljIGtleSB0byB0aGUgaG9sZGVyIG9mIGl0cyBwcml2YXRlIGtleSwgaW5jbHVk aW5nIGJ1dCBub3QgbGltaXRlZCB0byBleHBpcmF0aW9uIG9mIGEgY2VydGlmaWNhdGlvbiwgcmV2 b2NhdGlvbiBvZiBhIGNlcnRpZmljYXRpb24sIHByaXZhdGUga2V5IGR1cGxpY2F0aW9uIGRldGVj dGlvbiwga2V5IGRpc2Nsb3N1cmUsIG9yIGxvc3Mgb2YgcHJpdmF0ZSBrZXkgbWF0ZXJpYWwuDQoN ClRoZSByZWFzb24gSSBwdXQgaXQgdGhpcyB3YXkgaXMgYmVjYXVzZSBpdCBhbGwgcmVsYXRlcyB0 byB0aGUgaG9sZGVyIG9mIHRoZSBwcml2YXRlIGtleSwgdGhlIG9uZSB3aG8gaGFzIHRvIGRvIHNv bWV0aGluZyB3aGVuIGhlIGRpc2NvdmVycyB0aGF0IGhpcyBjZXJ0aWZpY2F0ZSBpcyBzdWRkZW5s eSBpbnZhbGlkLiAgVG8gdGhhdCBwZXJzb24sIGFsbCBldmVudHVhbGl0aWVzIGFwcGVhciB0aGUg c2FtZSwgYW5kIGFsbCBoYXZlIHRoZSBzYW1lIHJlY292ZXJ5OiByZWtleSwgcmVlbnJvbGwsIHJl aW5zdGFsbC4NCg0KPiBOb3RlIHRoYXQgdGhlcmUgYXJlIHNvbWUgY29udGV4dHMgKGUuZy4gc2Vu ZGluZyBhbiBlLW1haWwpIHdoZXJlIHRoZQ0KPiBwZWVyIGRvZXNuJ3QgaGF2ZSBhIGNoYW5jZSB0 byBwcmVzZW50IHlvdSB3aXRoIGEga2V5IGZvciB5b3UgdG8NCj4gZXZhbHVhdGUuICBpbiB0aG9z ZSBjb250ZXh0cywgeW91ciB0b29scyB3aWxsIGFjdHVhbGx5IG5lZWQgdG8gc2VsZWN0IGENCj4g c2luZ2xlIGtleSBmcm9tIHRoZSB2YXJpb3VzIChob3BlZnVsbHkgcmVkdW5kYW50LCBjb3Jyb2Jv cmF0aXZlKQ0KPiBkaXNjb3ZlcnkgbWVjaGFuaXNtcyBhdmFpbGFibGUgdG8gdGhlbS4gIFNvIGlu IHRob3NlIGNvbnRleHRzLCAidGhlIiA+IGlzIGEgbGVnaXRpbWF0ZSBhcnRpY2xlIHRvIHVzZS4N Cg0KVGhhdCBpcyBvbmx5IHRoZSBjYXNlIHdoZXJlIHlvdSdyZSBpbml0aWFsbHkgbG9va2luZyBm b3IgYSBrZXkgdGhhdCB0aGUgbWFpbGJveCBob2xkZXIgY2FuIHJlY2VpdmUgbWVzc2FnZXMgYWRk cmVzc2VkIHRvLiAgQWZ0ZXIgeW91IHNlbmQgYSBtZXNzYWdlIHdpdGggb25lIG9yIG1vcmUgb2Yg eW91ciBvd24ga2V5cyB0aGF0IHlvdSBjYW4gcmVjZWl2ZSBtZXNzYWdlcyBhZGRyZXNzZWQgdG8s IHRoZSBpbml0aWFsIHJlY2lwaWVudCBjYW4gcmVwbHkgd2l0aCBzb21lIHJlYWwga2V5cy4NCg0K V2h5IG5vdCBhIGRpc2NvdmVyeSBtZWNoYW5pc20gY2FsbGVkICJRUiBjb2RlIG9uIGEgY2FyZCI/ ICBCdXNpbmVzcyBjYXJkcyBhcmUgZWFzeSB0byBmb3JnZSwgc28geW91J2Qgd2FudCBzb21lIGZv cm0gb2YgY2VydGlmaWNhdGlvbiBvbiB0aGUgcmVwbHkgYmVmb3JlIHlvdSByZWxpZWQgb24gaXQs IGJ1dCBmb3IgaW5pdGlhbCBjb250YWN0IGl0IG1pZ2h0IHdvcmsuDQoNCi1LeWxlIEgNCg== --gmsm1.9.5eqgy99w2ulu19ixfjzpm2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMDQyMzI3MTNaMCMGCSqGSIb3DQEJBDEWBBSUVX59N6iZIEBfjqNq7q8+ l4cGPDBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAJPaK+KPDlivhFNYgFL+xFTNn4ZG/4JD+BFCGXzsgJaPI0mJSj86vEQfXTzhdxnzYGghz fnPmrw3w2K6Fmws7n+gA7UQxt16MKk+SizCPt/QU/CqgwqmPi0Ke2tF/grQGmRXCX1/92lkIOlnJ 5F6AZ8+J1rXzgCh27tFikrqR/UiQ6vRXg+qZMF6at7y4v+POpz+6VShgYQyNzqUDFhuOLAcQZDnQ NuPnjsAsmcGX4SAaliaP6L6d3l6S8cH5/Km3+MwdrbVrUqGvGCpgwUIuVqP/aoPVEHDG6tnRpJRQ az+Nrtpy5AenSgXe0E+Dwoh1lNlxHpbJ/qxvOMNMREYJMQAAAAAAAA== --gmsm1.9.5eqgy99w2ulu19ixfjzpm2-- From demoss.matt@gmail.com Sat Feb 4 17:00:20 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D0121F851A for ; Sat, 4 Feb 2012 17:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03ySnplFcy4T for ; Sat, 4 Feb 2012 17:00:20 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E5F4921F850F for ; Sat, 4 Feb 2012 17:00:19 -0800 (PST) Received: by qan41 with SMTP id 41so2976125qan.10 for ; Sat, 04 Feb 2012 17:00:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=FUK3e3MdLeP/3FiVdRslbMgLSW2Ak3gSk6Ki89rpPyw=; b=DofHJ1oa2IrHASlB8u1xyIPmJ73vXMDkY0wUGtmDJf+HeSRyOuliBRUgnSCFvC8usw uHSbJ3TwVhnMTVsBLU3P4U0KAHoaQWHwy6xAEeoYcY6TdQQy0CKrYYxG1Y5ZHoTozxRO caHpz2P5zlfqv3auZ5NrIUlyLXP/iwAUUQofE= Received: by 10.224.116.144 with SMTP id m16mr14829517qaq.19.1328403619427; Sat, 04 Feb 2012 17:00:19 -0800 (PST) Received: from matt-seven.dc.dc.cox.net (ip72-192-252-147.dc.dc.cox.net. [72.192.252.147]) by mx.google.com with ESMTPS id eb5sm23375293qab.10.2012.02.04.17.00.18 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Feb 2012 17:00:18 -0800 (PST) Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: therightkey@ietf.org References: <62F4ED71-4893-458D-B2F1-0651D85ACE3A@bbn.com> <4F21B25C.7070406@fifthhorseman.net> <20120126210653.GU16280@mail.yitter.info> <84A92419-9A72-41FA-BDD8-4E096EC5A952@virtualized.org> <14A0F2F6-E953-4C32-848F-22DEDB0A60A0@bbn.com> Date: Sat, 04 Feb 2012 19:59:50 -0500 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Matt DeMoss" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.61 (Win32) Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 01:00:20 -0000 >>>>> As security engineers, our role is to (a) reduce the number of >>>>> entities we trust; (b) reduce the extent to which we trust the >>>>> remaining trusted entities; and (c) determine the trustworthiness of >>>>> trusted entities. A system with voting like Convergence (depending on configuration) has the nice property that (b) shrinks as (a) grows, and we could potentially care less about (c) except to provide some kind of assurance that individual entities are in fact individual. From kent@bbn.com Mon Feb 6 09:52:45 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C918721F8475 for ; Mon, 6 Feb 2012 09:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.997 X-Spam-Level: X-Spam-Status: No, score=-104.997 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2CWipplX+5M for ; Mon, 6 Feb 2012 09:52:45 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 86D3821F84B4 for ; Mon, 6 Feb 2012 09:52:43 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:41141 helo=[10.120.130.185]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RuSk6-000Jnq-C3; Mon, 06 Feb 2012 12:52:42 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 6 Feb 2012 11:25:55 -0500 To: "Kyle Hamilton" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: therightkey@ietf.org Subject: Re: [therightkey] Why the focus on The? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 17:52:45 -0000 >>... > >Compromise (n): Any reduction in the utility of a public key to the >holder of its private key, including but not limited to expiration >of a certification, revocation of a certification, private key >duplication detection, key disclosure, or loss of private key >material. cert expiration and revocation are not considered compromises in the security literature. this is an overly broad definition. Steve From stephen.farrell@cs.tcd.ie Mon Feb 6 14:44:55 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE9411E80AC for ; Mon, 6 Feb 2012 14:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAqK61dlgpY8 for ; Mon, 6 Feb 2012 14:44:54 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id ABF3311E8096 for ; Mon, 6 Feb 2012 14:44:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0B48A153C17 for ; Mon, 6 Feb 2012 22:44:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1328568290; bh=1le7KljwZfrmOk7UFSvMTxYa E3O5dXo7j5JuNOJ0SQw=; b=5t8YvOfvlI1yO2PczEL5sGSwWDURg+PYAeGAtUCV A9ZYSF4Kcd5kTlOTBfL3I9ZjDjOUOR1s3AJw3sEZ4LroxgQ8PNGK79WoCGkU7uQA cvpMP1s2Rq7TiB6CKcMAWoh5jS5Vehr7rFGmbMgOnryYPPs8t2MrBgzKDU4gbQ/6 2M2uY3+LYbUd2kp5KJLfAD/X0u5Kz2bArC1qswZZcJnVFm1mv+J+jmK7SrsH05eG E+aq46LJf114zSBOKwHzUTbxVbDzB0D3sk8nwp6Ra5WdOSGnt13Zz0u4y27auHSY v0xqpMpbeq1sEM9CaMTi42Gfkz+lIR7+Zgr7Z34kq7uJ9w== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id V6y-gMfn+jx2 for ; Mon, 6 Feb 2012 22:44:50 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.41.7.174]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AE6EF153C16 for ; Mon, 6 Feb 2012 22:44:50 +0000 (GMT) Message-ID: <4F3057E2.6060502@cs.tcd.ie> Date: Mon, 06 Feb 2012 22:44:50 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "therightkey@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [therightkey] Paris too soon for a meeting... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 22:44:55 -0000 Hi all, I've been watching the list with interest and while there have been some good ideas and discussion on here, I don't get the impression that this is really ready for a productive BoF in Paris. So as of now I won't be proposing to schedule a slot for this group. If you disagree, or if you're not sure but would like to try push for a BoF, that's great but you need to get moving quickly, proposing concrete topics for a BoF. To have any chance of happening, that needs to be done and dusted *this* week. The IETF can supply a room and logistics, and I can supply a BoF chair, but the people on the list need to be the ones proposing stuff and I've not seen enough of that so far. If, as I suspect, its still a bit early for a BoF on this topic, but a bunch of you will be at the Paris IETF in any case, then you can self-organise a bar-BoF/side-meeting, (if you do, please try do it in a real bar:-). You don't need me or anyone else to help with that, just do it if you want. Meanwhile even if nothing happens for this in Paris, the list is here and you'll hopefully get to discussing some concrete proposals in the near future. There are specific (if not that well documented) proposals out there and I'd love to see their proponents arguing their relative merits in detail so's we could see if there are things that the IETF could/should be doing. Regards, Stephen. PS: On the list name and implied cardinality: I was the one who came up with that, and used it for the one and only reason that it was the least bad thing suggested. Its just not really significant. (But maybe if it inspires debate it was a good choice;-) PPS: If you're just shy or not sure about IETF process stuff, but would like to propose something, feel entirely free to mail me off-list and I'll try help if I can. From rbarnes@bbn.com Mon Feb 6 16:43:58 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C430C11E80B8 for ; Mon, 6 Feb 2012 16:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAz2gricHKZR for ; Mon, 6 Feb 2012 16:43:58 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 25F5811E80B3 for ; Mon, 6 Feb 2012 16:43:58 -0800 (PST) Received: from [128.89.254.143] (port=58689 helo=dhcp-221-145.meetings.nanog.org) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RuZA3-000Pum-Te; Mon, 06 Feb 2012 19:43:56 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4F3057E2.6060502@cs.tcd.ie> Date: Mon, 6 Feb 2012 16:43:54 -0800 Content-Transfer-Encoding: 7bit Message-Id: <3E788199-DF70-4747-8F36-3083F182A148@bbn.com> References: <4F3057E2.6060502@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Paris too soon for a meeting... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 00:43:58 -0000 > If, as I suspect, its still a bit early for a BoF on > this topic, but a bunch of you will be at the Paris > IETF in any case, then you can self-organise a > bar-BoF/side-meeting, (if you do, please try do it > in a real bar:-). You don't need me or anyone else > to help with that, just do it if you want. ^^^ This I would be up for a bar BoF. --Richard From aerowolf@gmail.com Mon Feb 6 21:26:10 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751FE11E80EA for ; Mon, 6 Feb 2012 21:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=1.381, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LD+ag0AAw7VN for ; Mon, 6 Feb 2012 21:26:08 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 783B611E80E0 for ; Mon, 6 Feb 2012 21:26:08 -0800 (PST) Received: by iagf6 with SMTP id f6so11454976iag.31 for ; Mon, 06 Feb 2012 21:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=OGE7kGVg5FXwBzmXOzXY1vdN/KPnUa/SN6qlTE4AHg8=; b=qc57BQtVePgo2PNpPiCDmDw9JEjW9SXUnMgT/ED//9K1lxPx+NHflwyzdgMgI7dlHT Yg9wiUueXwVGLfdDG2pDB+1NGFPRyC1gw+zJ+efSBWY9JI0ztMkYPguhbF/Ibr/2E6U0 HLpTMMfzDjkQxPLqowPEWepar0cMos2++Irsw= Received: by 10.42.153.201 with SMTP id n9mr19833626icw.14.1328592368195; Mon, 06 Feb 2012 21:26:08 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id l28sm31305921ibc.3.2012.02.06.21.26.03 (version=SSLv3 cipher=OTHER); Mon, 06 Feb 2012 21:26:04 -0800 (PST) From: "Kyle Hamilton" To: "Jon Callas" Date: Mon, 6 Feb 2012 21:25:55 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgychl2dhnhwy061x3b2 Cc: therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 05:26:10 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgychl2dhnhwy061x3b2 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit On Wed, Feb 1, 2012 at 12:28 AM, Jon Callas wrote: > You might trust your mother, but do you trust your mother to set up > your VPN? Finally, someone talking some sense. > And keys are just labels. I'm enough of an SPKI revanchist > to say that keys are just names or labels. You can no more > determine trustworthiness from a mere name than you can > tell a book by its cover. To talk about trust, let alone > trust*worththiness*, you're talking reputation. Keys, or values derived from keys, are the only identities the computer can really comprehend. Everything else, including certifications, is simply metadata. Certifications are statements of reputation. Reputation doesn't exist because we need to identify others, identifiers exist because we need reputation. Identity certificates are convenient indexes into records, but we don't actually need them to contain everything that they contain. All they really need to contain is a statement that the CA knows who enrolled the key, which is basically what an otherwise-unidentified certification is in any case. Using the same key across multiple places may not seem to be something which has turned out to be a problem in practice, in that TLS sites use the same keys across every client. However, it's a major reason why client-side authentication isn't accepted by the individual consumer. The threat is that businesses will do anything to make a buck, so we must assume that they will be willing (no matter what they say their privacy policies are, because statistically at least one of them is lying) to perform back-end database matching. This means that we can't rely on a single certified public key. We can't even rely on knowing ahead of time how many keys we need to enroll. We can't accept constant DNs. We can't accept static keys. We can't accept static certifications. As a result, we need certifications to be API-enrollable. The API must allow the user to able to specify what aspects of his certified identity are placed into the certificate. Certifications should be a marginal cost item (a penny or two), because there is something of a queue for the certifier token service. They should not be free, but they shouldn't be expensive either. We should focus on providing as many chains of authority as are necessary to ensure security. Perhaps enroll new keys using both a personal enrollment key and a device enrollment key, so that it's possible to identify which device was compromised? -Kyle H --gmsm1.9.5eqgychl2dhnhwy061x3b2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMDcwNTI1NTVaMCMGCSqGSIb3DQEJBDEWBBR1sTDFs+TVb7yAHix8qII5 iJXQjTBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEApj20owDyTW5MgSDom+YPnBjNInnBitq1dJTyilqqVM0qko2kc5wji24JQgOmzIjXxqbW Y4/WzpvbwKfO+yRpqaHGzjn5iDVNizW7HxzZ6vfheCzL6hArE0AdKVWDemd8UZvH6GoxOHz7fMVL dTDBAkHf9z6Nlbc4VIPwKqSh9bO04icuG2JWK6gl3k7efjPoKo5okCs5CV9D3gX/SnUyCIVt6fG/ YnCF0PgZt1TsjLFNsiX10Z+ntns+zOJgZm3iezIexwsVM6rR1r+oh5Lhzeb/E5cdXRGGbb3QRTci /EZhFwVOq7KRVSLXi6buFxvvdyovgjT6pfQlzGgbeA019QAAAAAAAA== --gmsm1.9.5eqgychl2dhnhwy061x3b2-- From Jeff.Hodges@KingsMountain.com Tue Feb 7 08:01:31 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04FA21F884A for ; Tue, 7 Feb 2012 08:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.255 X-Spam-Level: X-Spam-Status: No, score=-99.255 tagged_above=-999 required=5 tests=[AWL=-0.619, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kO3wGOyUTw8b for ; Tue, 7 Feb 2012 08:01:31 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 00D2F21F8843 for ; Tue, 7 Feb 2012 08:01:30 -0800 (PST) Received: (qmail 26508 invoked by uid 0); 7 Feb 2012 16:01:23 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 7 Feb 2012 16:01:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=wwsDANTI4eKwD5VnprpLhDK3Euv2YbudyUua8aTKqO8=; b=pDLnLlAw/yr57QpRSGlx+bOfSSq3N/wcwpha502eOHfpSjf3pZ+DZxoT8kIkvB3H+ahC9s3OTwdNnX9Iv2icmObROmKI7kadwnsIihaLktcJ86ZF8g1YxhX1P0nFUvrJ; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.182]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RunTv-0008Tv-24 for therightkey@ietf.org; Tue, 07 Feb 2012 09:01:23 -0700 Message-ID: <4F314AD2.3030905@KingsMountain.com> Date: Tue, 07 Feb 2012 08:01:22 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [therightkey] Paris too soon for a meeting... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:01:31 -0000 Excellent summary Steve, thanks. I'm up for a bar-BoF/side-meeting in Paris. > There are specific (if not that well documented) > proposals out there and I'd love to see their proponents > arguing their relative merits in detail so's we > could see if there are things that the IETF could/should > be doing. Agreed. I think that those folks having not spoken up or dived into this discussion is telling wrt how early all this is. AFAIK there will be some in-the-wild experiments run by various folk and that should further inform discussions such as this. =JeffH From Jeff.Hodges@KingsMountain.com Tue Feb 7 08:03:09 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E20121F881B for ; Tue, 7 Feb 2012 08:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.218 X-Spam-Level: X-Spam-Status: No, score=-99.218 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfeF2wcZfnss for ; Tue, 7 Feb 2012 08:03:08 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id B963421F862A for ; Tue, 7 Feb 2012 08:03:08 -0800 (PST) Received: (qmail 20225 invoked by uid 0); 7 Feb 2012 16:03:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 7 Feb 2012 16:03:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=UHxYN7eMWdIQNafhiakvQdMRVzZq9Ryimi62khlVd8M=; b=6dB8NsEB32m3a2v6DkBwq7RO722xFmSIJ3jsEhKkAvZbBjF2Rc3bDEwHlqe+EB6k8fRR1p5qBnD1BmTI0nSCK/mUMSA1KWsEyj2YPbX0fBa8lX7WnVfidmF58slvtl+y; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.182]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RunVb-0002MP-Ja for therightkey@ietf.org; Tue, 07 Feb 2012 09:03:07 -0700 Message-ID: <4F314B39.5050207@KingsMountain.com> Date: Tue, 07 Feb 2012 08:03:05 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [therightkey] wrt experiments: Revocation checking and Chrome's CRL X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:03:09 -0000 wrt experiments, see for example.. Revocation checking and Chrome's CRL (AGL) http://www.imperialviolet.org/2012/02/05/crlsets.html [cryptography] Chrome to drop CRL checking http://lists.randombit.net/pipermail/cryptography/2012-February/002236.html =JeffH From kent@bbn.com Tue Feb 7 11:56:35 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642B211E80C8 for ; Tue, 7 Feb 2012 11:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.203 X-Spam-Level: X-Spam-Status: No, score=-106.203 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TW3nFKyhIV+U for ; Tue, 7 Feb 2012 11:56:34 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBBC11E80A6 for ; Tue, 7 Feb 2012 11:56:34 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:58609 helo=[10.120.131.43]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rur9T-0002BJ-Eb; Tue, 07 Feb 2012 14:56:31 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 7 Feb 2012 14:55:49 -0500 To: "Kyle Hamilton" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: therightkey@ietf.org, Jon Callas Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 19:56:35 -0000 At 9:25 PM -0800 2/6/12, Kyle Hamilton wrote: >... > >>And keys are just labels. I'm enough of an SPKI revanchist >>to say that keys are just names or labels. You can no more >>determine trustworthiness from a mere name than you can >>tell a book by its cover. To talk about trust, let alone >>trust*worththiness*, you're talking reputation. > >Keys, or values derived from keys, are the only identities the >computer can really comprehend. Everything else, including >certifications, is simply metadata. Keys are not really great identifiers; they change, they are not human meaningful (and thus there has to be another layer of mapping between key and human-readable IDs, which creates more vulnerabilities), etc. We used to have a WG that pursued the notion of keys as IDs (SPKI) in certs, but it died. >Certifications are statements of reputation. if managed properly, public key certs can be assertions of identity, relative to a context. they need not be statements of reputation, but they can be links between entities and reputations. Reputations can be asserted separately, e.g., Good Housekeeping Seal of Approval, UL approval, WiFi Certifiied, ... > Reputation doesn't exist because we need to identify others, >identifiers exist because we need reputation. an interesting perspective, but not one you'll tend to find in the secruity literature. in some contexts, reputation is a way for people to acquire additional inputs when making a decision to trust a person or org. in some contexts, and depending on how one defines reputation, reputation may represent authorization. but, there are contexts in which reputation and authorization are independent of identifiers, so ... > Identity certificates are convenient indexes into records, but we >don't actually need them to contain everything that they contain. >All they really need to contain is a statement that the CA knows who >enrolled the key, which is basically what an otherwise-unidentified >certification is in any case. I don't know what "otherwise-unidentified certification" means. Also, I think there are a few useful additional fields in certs, e.g., validity interval. >Using the same key across multiple places may not seem to be >something which has turned out to be a problem in practice, in that >TLS sites use the same keys across every client. However, it's a >major reason why client-side authentication isn't accepted by the >individual consumer. most folks believe that client certs are not widely used because of the added hassle to issue them, poor cert management tools for users who need to use the certs, and associated private keys, across multiple machines, and the inertia associated with moving away from passwords. >The threat is that businesses will do anything to make a buck, so we >must assume that they will be willing (no matter what they say their >privacy policies are, because statistically at least one of them is >lying) to perform back-end database matching. finally a statement which which I can agree. >This means that we can't rely on a single certified public key. We >can't even rely on knowing ahead of time how many keys we need to >enroll. We can't accept constant DNs. We can't accept static keys. >We can't accept static certifications. I agree that users ought to have multiple keys/certs, and have done so in papers and talks since 1997. I don't see how this relates to constant names, static keys or static certification. >As a result, we need certifications to be API-enrollable. The API >must allow the user to able to specify what aspects of his certified >identity are placed into the certificate. Certifications should be >a marginal cost item (a penny or two), because there is something of >a queue for the certifier token service. They should not be free, >but they shouldn't be expensive either. there are other models of cert issuance that might yield free certs, with limits on the context in which each cert is used. such limits help protect user privacy, because a user need not employ the same cert with a lot of different services. but, any model that requires user to have a number of certs must contend with the user interface problems to which I alluded above. >We should focus on providing as many chains of authority as are >necessary to ensure security. Perhaps enroll new keys using both a >personal enrollment key and a device enrollment key, so that it's >possible to identify which device was compromised? we don't require the same level of security for all transactions. if we assume that the cost to issue a credential may be proportional to the assurance associated with its issuance (which may not be true in all cases), then we might have very cheap, maybe free credentials for many transactions, and better ones, perhaps more expensive ones, for a more limited set of transactions. One size need not fit all re issuance. But it is nice if one format can be used to reduce costs for CAs and RPs. Steve From joe@oregon.uoregon.edu Tue Feb 7 12:26:56 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C850B21F86B2 for ; Tue, 7 Feb 2012 12:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZwNWnatbl4p for ; Tue, 7 Feb 2012 12:26:55 -0800 (PST) Received: from grey.uoregon.edu (grey.uoregon.edu [128.223.214.89]) by ietfa.amsl.com (Postfix) with SMTP id 0332E21F86A8 for ; Tue, 7 Feb 2012 12:26:54 -0800 (PST) Date: Tue, 7 Feb 2012 12:05:17 -0800 (PST) Message-Id: <12020712051780_4AE3A@oregon.uoregon.edu> From: "Joe St Sauver" To: kent@bbn.com X-VMS-To: SMTP%"kent@bbn.com" X-VMS-Cc: SMTP%"therightkey@ietf.org" Cc: therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 20:26:56 -0000 Kent commented on Kyle Hamilton's remarks... #>Using the same key across multiple places may not seem to be #>something which has turned out to be a problem in practice, in that #>TLS sites use the same keys across every client. However, it's a #>major reason why client-side authentication isn't accepted by the #>individual consumer. # #most folks believe that client certs are not widely used because of #the added hassle to issue them, poor cert management tools for users #who need to use the certs, and associated private keys, across #multiple machines, and the inertia associated with moving away from #passwords. This is actually a fascinating question, and one where the answer you get for "Why don't people deploy client certs?" varies from person to person. I attempt to capture a little of that in a talk I did a week or so ago at Internet2/ESNet Joint Techs in Baton Rouge: "Client Cert Deployment Models and Hardware Tokens/Smart Cards" http://pages.uoregon.edu/joe/client-cert-models/jt-louisiana.pdf It wasn't possible to do an exhaustive analysis of that question in a 20 minute slot, but you can at least get an idea of what we're seeing... #>This means that we can't rely on a single certified public key. We #>can't even rely on knowing ahead of time how many keys we need to #>enroll. We can't accept constant DNs. We can't accept static keys. #>We can't accept static certifications. # #I agree that users ought to have multiple keys/certs, and have done #so in papers and talks since 1997. I don't see how this relates to #constant names, static keys or static certification. FWIW, even the Feds issue multiple certs, if only because some need to be non-repudiable (e.g., for signing) while others need to be escrowed for potential recovery (or authorized monitoring) of encrypted content (at least in a Federal environment). That said, given my druthers, I'd prefer a single client cert to use for MOST purposes, just as I prefer to use a single PGP/GPG key -- it's easier, and reduces correspondent confusion. #>As a result, we need certifications to be API-enrollable. The API #>must allow the user to able to specify what aspects of his certified #>identity are placed into the certificate. Certifications should be #>a marginal cost item (a penny or two), because there is something of #>a queue for the certifier token service. They should not be free, #>but they shouldn't be expensive either. I'd also argue that there's a discontinuity in potential cert prices: you can have free certs, and you can have not free certs, but you probably can't have really really cheap certs (e.g., in the couple of cent range) for all the reasons that micropayments have traditionally been tricky online, to say nothing of customer expectations ("Hey buddy, I paid a dime for that cert, I want to see some SERVICE when I have a problem!") I'd also assert that the cost of the cert is trivial relative to the cost of the secure storage device that might hold the cert (e.g., a USB format hard token, or a smart card and reader). #there are other models of cert issuance that might yield free certs, #with limits on the context in which each cert is used. such limits #help protect user privacy, because a user need not employ the same #cert with a lot of different services. but, any model that requires #user to have a number of certs must contend with the user interface #problems to which I alluded above. I concur that multiple certs equal user confusion unless you can really make it pretty darn clear (e.g., jsmith+signing@example.com or jsmith+encryption@example.com, for example). If I want non-attributability, I'm not sure that I want to be using a cert at all #>We should focus on providing as many chains of authority as are #>necessary to ensure security. Perhaps enroll new keys using both a #>personal enrollment key and a device enrollment key, so that it's #>possible to identify which device was compromised? # #we don't require the same level of security for all transactions. if #we assume that the cost to issue a credential may be proportional to #the assurance associated with its issuance (which may not be true in #all cases), then we might have very cheap, maybe free credentials for #many transactions, and better ones, perhaps more expensive ones, for #a more limited set of transactions. One size need not fit all re #issuance. But it is nice if one format can be used to reduce costs #for CAs and RPs. An interesting approach, BTW, is the one that CILogon takes, leveraging federated authentication to mint certs for secure access to cyber infrastructure -- see http://www.cilogon.org/ for more information about this approach, if interested. Regards, Joe From kent@bbn.com Tue Feb 7 14:25:53 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B05321F870F for ; Tue, 7 Feb 2012 14:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.229 X-Spam-Level: X-Spam-Status: No, score=-106.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NLFR4RN-GuH for ; Tue, 7 Feb 2012 14:25:52 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2897621F86FA for ; Tue, 7 Feb 2012 14:25:52 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:35788 helo=[10.120.131.43]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RutTx-000GAd-NP; Tue, 07 Feb 2012 17:25:50 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <12020712051780_4AE3A@oregon.uoregon.edu> References: <12020712051780_4AE3A@oregon.uoregon.edu> Date: Tue, 7 Feb 2012 17:25:43 -0500 To: "Joe St Sauver" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 22:25:53 -0000 At 12:05 PM -0800 2/7/12, Joe St Sauver wrote: >... > >This is actually a fascinating question, and one where the answer you >get for "Why don't people deploy client certs?" varies from person to >person. I attempt to capture a little of that in a talk I did a week >or so ago at Internet2/ESNet Joint Techs in Baton Rouge: > >"Client Cert Deployment Models and Hardware Tokens/Smart Cards" >http://pages.uoregon.edu/joe/client-cert-models/jt-louisiana.pdf > >It wasn't possible to do an exhaustive analysis of that question in >a 20 minute slot, but you can at least get an idea of what we're seeing... I think there are multiple reasons why client certs have not taken off, based on 20+ years of experience in the area. We provided a client cert system for a financial firm in the early 90's. It was easy to use, bootstrapped from the password-based system that the firm used. But, because there were no good tools to allow users to move certs and private keys among client machines, it was eventually turned off. >... > >FWIW, even the Feds issue multiple certs, if only because some need to >be non-repudiable (e.g., for signing) while others need to be escrowed >for potential recovery (or authorized monitoring) of encrypted content >(at least in a Federal environment). The 3-cert CAC is not what I was suggesting. (And the reasons there are separate certs for sigs vs. key transport is because users need to perform key recovery for themselves for old e-mail, rather than for monitoring.) What I was advocating is certs with different IDs, each appropriate for a well-defined set of contexts, issued by CAs that are authoritative for identity in specific contexts. >That said, given my druthers, I'd prefer a single client cert to use for >MOST purposes, just as I prefer to use a single PGP/GPG key -- it's >easier, and reduces correspondent confusion. It is easier, but is undermines privacy and raises the question of what CA is appropriate for ALL contexts. >... > >I'd also assert that the cost of the cert is trivial relative to the >cost of the secure storage device that might hold the cert (e.g., a >USB format hard token, or a smart card and reader). The cost of managing a cert has a lot to do with the nature of the relationship between the issuer and subject, and the liability that the CA incurs as a result of issuing the cert. For example, I have relationships with credit card issuers. They make money when I use my cards. If they issued certs to me, that could be used in lieu of plastic, because they believed the security could be better, I probably would not pay for the cert. >... >I concur that multiple certs equal user confusion unless you can really >make it pretty darn clear (e.g., jsmith+signing@example.com or >jsmith+encryption@example.com, for example). not the sort of IDs I had in mind. I have an identity with Visa, with Amex, with UA, US, Hertz, Avis, etc. Each is authorized to identify me in certain contexts, and my ID is context specific. I also have a relationship entities who provide e-mail services, and they are the best entities to act as CAs when my e-mail address is the subject name. It's not about signing vs. encryption, but more about what entity is authoritative for identifying me. >... > >An interesting approach, BTW, is the one that CILogon takes, leveraging >federated authentication to mint certs for secure access to cyber >infrastructure -- see http://www.cilogon.org/ for more information about >this approach, if interested. federated authentication systems using certs generally seem to be motivated because folks can make cross-certification work properly. other federated auth systems seem to be based on having one org trust another to assert and identity for a user know to the second, but not the first. that's a recipe for secruity problems. Steve From ryan.hurst@globalsign.com Tue Feb 7 15:35:29 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EC011E807F for ; Tue, 7 Feb 2012 15:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ompB81K-OvmM for ; Tue, 7 Feb 2012 15:35:28 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF1F121F8705 for ; Tue, 7 Feb 2012 15:35:26 -0800 (PST) Received: by dakl33 with SMTP id l33so7073661dak.31 for ; Tue, 07 Feb 2012 15:35:26 -0800 (PST) Received: by 10.68.238.229 with SMTP id vn5mr62605980pbc.39.1328657726673; Tue, 07 Feb 2012 15:35:26 -0800 (PST) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id h6sm418067pbg.5.2012.02.07.15.35.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 15:35:26 -0800 (PST) From: "Ryan Hurst" To: "'Stephen Kent'" , "'Joe St Sauver'" Date: Tue, 7 Feb 2012 15:35:24 -0800 Message-ID: <008d01cce5f1$2b322f50$81968df0$@globalsign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Aczl7t+k0ewvxO63TCCu24Lbblwmgw== Content-Language: en-us Cc: therightkey@ietf.org Subject: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 23:35:29 -0000 Forking thread as I fee compelled to discuss client certificates but I am not sure its related to the original thread. I also worked on some moderately successful client certificate solutions, their success however was only possible because of the pain tolerance for the communities they served; by objective measures they just were not good enough and in my opinion the reasons are pretty straight forward, they are: 1. There is no way to "log out", by authenticating the user as part of the TLS session the authentication is cached with the session; browsers all (rightfully so) implement session caching, this means that to log out one in-essence needs to close the entire browser and in a world of tabs this is a total non-starter (as an FYI there is a hack to do this in IE but it's far from perfect - see http://www.unmitigatedrisk.com/archive/2007/03/12/29.aspx) 2. Usability, the bar for a usable system on the public internet is significantly different than that in a corporate or government environment; the basic separation of pin collection and credential selection alone makes the usability characteristics of the client authentication experience too poor to adopt broadly. 3. Theming and Branding, however hard it is for us as technologists to accept the ability for site the create an authentication experience that is consistent with the rest of their site is mandatory for adoption in these scenarios. 4. Reasonable certificate lifecycle management for un-managed environments, I think this has been solved to a great extent with Windows 7 and the WS-TRUST enrollment work they did; it works very well but that's just Window and just Windows 7. 5. Hardware support for smart cards, there is a resistance in the smart card community to normalize on a single card edge; PIV is probably the most reasonable one that is out there but it presumes management done in an environment like the DOD (admin keys, proprietary management apis, etc); There are lots of potential solutions but when at Microsoft I worked with folks on a specification (that is supported in Windows 7 and up) to try to address this - http://www.unmitigatedrisk.com/archive/2010/04/09/227.aspx On a related not, BrowerID goes a long way to address some of these concerns (though it has work to do yet). Ryan -----Original Message----- From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Tuesday, February 07, 2012 2:26 PM To: Joe St Sauver Cc: therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? At 12:05 PM -0800 2/7/12, Joe St Sauver wrote: >... > >This is actually a fascinating question, and one where the answer you >get for "Why don't people deploy client certs?" varies from person to >person. I attempt to capture a little of that in a talk I did a week or >so ago at Internet2/ESNet Joint Techs in Baton Rouge: > >"Client Cert Deployment Models and Hardware Tokens/Smart Cards" >http://pages.uoregon.edu/joe/client-cert-models/jt-louisiana.pdf > >It wasn't possible to do an exhaustive analysis of that question in a >20 minute slot, but you can at least get an idea of what we're seeing... I think there are multiple reasons why client certs have not taken off, based on 20+ years of experience in the area. We provided a client cert system for a financial firm in the early 90's. It was easy to use, bootstrapped from the password-based system that the firm used. But, because there were no good tools to allow users to move certs and private keys among client machines, it was eventually turned off. >... > >FWIW, even the Feds issue multiple certs, if only because some need to >be non-repudiable (e.g., for signing) while others need to be escrowed >for potential recovery (or authorized monitoring) of encrypted content >(at least in a Federal environment). The 3-cert CAC is not what I was suggesting. (And the reasons there are separate certs for sigs vs. key transport is because users need to perform key recovery for themselves for old e-mail, rather than for monitoring.) What I was advocating is certs with different IDs, each appropriate for a well-defined set of contexts, issued by CAs that are authoritative for identity in specific contexts. >That said, given my druthers, I'd prefer a single client cert to use >for MOST purposes, just as I prefer to use a single PGP/GPG key -- it's >easier, and reduces correspondent confusion. It is easier, but is undermines privacy and raises the question of what CA is appropriate for ALL contexts. >... > >I'd also assert that the cost of the cert is trivial relative to the >cost of the secure storage device that might hold the cert (e.g., a USB >format hard token, or a smart card and reader). The cost of managing a cert has a lot to do with the nature of the relationship between the issuer and subject, and the liability that the CA incurs as a result of issuing the cert. For example, I have relationships with credit card issuers. They make money when I use my cards. If they issued certs to me, that could be used in lieu of plastic, because they believed the security could be better, I probably would not pay for the cert. >... >I concur that multiple certs equal user confusion unless you can really >make it pretty darn clear (e.g., jsmith+signing@example.com or >jsmith+encryption@example.com, for example). not the sort of IDs I had in mind. I have an identity with Visa, with Amex, with UA, US, Hertz, Avis, etc. Each is authorized to identify me in certain contexts, and my ID is context specific. I also have a relationship entities who provide e-mail services, and they are the best entities to act as CAs when my e-mail address is the subject name. It's not about signing vs. encryption, but more about what entity is authoritative for identifying me. >... > >An interesting approach, BTW, is the one that CILogon takes, leveraging >federated authentication to mint certs for secure access to cyber >infrastructure -- see http://www.cilogon.org/ for more information >about this approach, if interested. federated authentication systems using certs generally seem to be motivated because folks can make cross-certification work properly. other federated auth systems seem to be based on having one org trust another to assert and identity for a user know to the second, but not the first. that's a recipe for secruity problems. Steve _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey From hallam@gmail.com Tue Feb 7 15:52:49 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EC721F85E5 for ; Tue, 7 Feb 2012 15:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMCpEob7PVeU for ; Tue, 7 Feb 2012 15:52:48 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 18E4D21F85B5 for ; Tue, 7 Feb 2012 15:52:48 -0800 (PST) Received: by obbwd15 with SMTP id wd15so10900897obb.31 for ; Tue, 07 Feb 2012 15:52:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HvNfTDuHqanmUkmIYZAmE/bDPu6H16q6zr/YLKg0xKs=; b=pqFu8vA7l9a8lPIXZ6bHQChkvEad8NJXSv9iiqkZQ1KDDEFxBp3diuo4XU0IYl/7At ruY23XmFccNv6L7pmfaQ5Wgz+4yk+sQ+6zkk052pSojeCrHbvZHsnFOMy3vxU/yDNein TQOPJBNuTkEDz8G9x9WFQXgxD63qphzugpf5o= MIME-Version: 1.0 Received: by 10.182.121.101 with SMTP id lj5mr23264258obb.39.1328658767668; Tue, 07 Feb 2012 15:52:47 -0800 (PST) Received: by 10.182.42.227 with HTTP; Tue, 7 Feb 2012 15:52:47 -0800 (PST) In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> Date: Tue, 7 Feb 2012 18:52:47 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: Joe St Sauver , therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 23:52:49 -0000 On Tue, Feb 7, 2012 at 5:25 PM, Stephen Kent wrote: > I think there are multiple reasons why client certs have not taken off, > based on 20+ years of experience in the area. We provided a client cert > system for a financial firm in the early 90's. It was easy to use, > bootstrapped from the password-based system that the firm used. But, because > there were no good tools to allow users to move certs and private keys among > client machines, it was eventually turned off. The reason I no longer believe in end-to-end solutions is that the endpoint for a public key is always a machine and the desired endpoint is a person. So what happens is that people talk past each other with engineers developing a scheme that prevents an attack the users don't care about and prevent implementation of controls that they consider essential, like spam filtering. Cardspace fell victim to a similar problem. The system was very secure but users no longer have a single machine that they use. Any scheme that does not take account of the fact that a user must be able to access their account from at lest fifteen different devices, some of which will be mobile and possibly lost is useless in the real world. The military can tollerate such systems because they will order people to use them. S/MIME with a private key shared to fifteen devices no longer looks very secure to me. In practice most email that is sent encrypted is encrypted using TLS. If we had an infrastructure that allowed mail servers to know that their corresponding servers required use of TLS, the man in the middle downgrade attack could be defeated. -- Website: http://hallambaker.com/ From ryan.hurst@globalsign.com Tue Feb 7 15:56:17 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8589521F8745 for ; Tue, 7 Feb 2012 15:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUhsP4iAaxbV for ; Tue, 7 Feb 2012 15:56:16 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id CEE4921F8734 for ; Tue, 7 Feb 2012 15:56:16 -0800 (PST) Received: by dakl33 with SMTP id l33so7086213dak.31 for ; Tue, 07 Feb 2012 15:56:16 -0800 (PST) Received: by 10.68.225.71 with SMTP id ri7mr62720890pbc.129.1328658975929; Tue, 07 Feb 2012 15:56:15 -0800 (PST) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id b7sm529076pba.2.2012.02.07.15.56.14 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Feb 2012 15:56:15 -0800 (PST) From: "Ryan Hurst" To: "'Phillip Hallam-Baker'" , "'Stephen Kent'" References: <12020712051780_4AE3A@oregon.uoregon.edu> In-Reply-To: Date: Tue, 7 Feb 2012 15:56:13 -0800 Message-ID: <00a701cce5f4$13ba5020$3b2ef060$@globalsign.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKAEVPbK0TXLjvi7gaLv9B9QIH16AJrLjeLAjcDz4iUprNiYA== Content-Language: en-us Cc: 'Joe St Sauver' , therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 23:56:17 -0000 A very good point, this is also one of the reasons deploying smart card authentication is difficult as well. Today people use IP Phones, mobile phones, tablets, desktops, kiosks and more; moving to a "require" solution for authentication requires one have a solution for all of these devices or you increase complexity without the benefit as you have to continue to support the weaker authentication schemes. Ryan -----Original Message----- From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker Sent: Tuesday, February 07, 2012 3:53 PM To: Stephen Kent Cc: Joe St Sauver; therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? On Tue, Feb 7, 2012 at 5:25 PM, Stephen Kent wrote: > I think there are multiple reasons why client certs have not taken > off, based on 20+ years of experience in the area. We provided a > client cert system for a financial firm in the early 90's. It was easy > to use, bootstrapped from the password-based system that the firm > used. But, because there were no good tools to allow users to move > certs and private keys among client machines, it was eventually turned off. The reason I no longer believe in end-to-end solutions is that the endpoint for a public key is always a machine and the desired endpoint is a person. So what happens is that people talk past each other with engineers developing a scheme that prevents an attack the users don't care about and prevent implementation of controls that they consider essential, like spam filtering. Cardspace fell victim to a similar problem. The system was very secure but users no longer have a single machine that they use. Any scheme that does not take account of the fact that a user must be able to access their account from at lest fifteen different devices, some of which will be mobile and possibly lost is useless in the real world. The military can tollerate such systems because they will order people to use them. S/MIME with a private key shared to fifteen devices no longer looks very secure to me. In practice most email that is sent encrypted is encrypted using TLS. If we had an infrastructure that allowed mail servers to know that their corresponding servers required use of TLS, the man in the middle downgrade attack could be defeated. -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey From mrex@sap.com Tue Feb 7 22:12:18 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E9921F8710 for ; Tue, 7 Feb 2012 22:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.621 X-Spam-Level: X-Spam-Status: No, score=-9.621 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_BACKHAIR_33=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db0j4ERcDEOP for ; Tue, 7 Feb 2012 22:12:17 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFB221F870E for ; Tue, 7 Feb 2012 22:12:16 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q186C8fK029069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Feb 2012 07:12:08 +0100 (MET) From: Martin Rex Message-Id: <201202080612.q186C7Nq003561@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Wed, 8 Feb 2012 07:12:07 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Feb 7, 12 06:52:47 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: joe@oregon.uoregon.edu, therightkey@ietf.org, kent@bbn.com Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 06:12:18 -0000 Phillip Hallam-Baker wrote: > > In practice most email that is sent encrypted is encrypted using TLS. > If we had an infrastructure that allowed mail servers to know that > their corresponding servers required use of TLS, the man in the middle > downgrade attack could be defeated. I'm sorry Phillip, but MTA<->MTA delivery with STARTTLS is thoroughly broken and effectively unfixable at the moment. Not only is there no secure algorithm to determine which domains use a TLS-enabled mail relay and which do not, but PKIX path validation can not be done because plenty of mail relays are using certs that do not validate under the (questionable) TLS X.509 PKI used by browsers, and server endpoint validation can not be done because exactly noone is carrying the Email domains in their SMTP Server certs for which these servers are authorized to receive mail, and several SMTP fanciers seem to be strongly attached to the idea that matching to the *result* of an MX lookup rather than to the EMail target domain would make sense security-wise (it doesn't). And then there are SMTP servers out there (e.g. @gmail.com), that, while being issued by a CA that is recognized under TLS X.509 PKI of browsers, neither matches the EMail target domain, nor does it match the insecure target of the MX record. In theory, DNSSEC could be used to solve several problems (indicating that a domain offers STARTTLS *plus* secure identification of acceptable MTA servers. But in the near term I expect a wide adoption of DNSSEC not more likely or faster than the wide adoption of IPv6 to solve the IPv4 address depletion... -Martin From diego@tid.es Tue Feb 7 23:52:51 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20E021F8619 for ; Tue, 7 Feb 2012 23:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.017 X-Spam-Level: X-Spam-Status: No, score=-4.017 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQiHW28oBpdA for ; Tue, 7 Feb 2012 23:52:49 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 324B421F8600 for ; Tue, 7 Feb 2012 23:52:43 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ200NEPDVT45@tid.hi.inet> for therightkey@ietf.org; Wed, 08 Feb 2012 08:52:41 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 07.95.02643.9C9223F4; Wed, 08 Feb 2012 08:52:41 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LZ200NEJDVT45@tid.hi.inet> for therightkey@ietf.org; Wed, 08 Feb 2012 08:52:41 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Wed, 08 Feb 2012 08:52:41 +0100 Date: Wed, 08 Feb 2012 08:52:39 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: Stephen Kent Message-id: <10ED67C0-F0ED-4D2C-B897-0BE97689EDF5@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [therightkey] Will the real RPF please stand up? Thread-index: AczmNqIhuKjZOEjuRHCktRYoaNjOOA== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-54-4f3229c95d64 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsXCFe9nqHtS08jf4NhxI4uPF36yODB6LFny kymAMYrLJiU1J7MstUjfLoEro//hc6aCBp6Kz0efMDYw3ufsYuTgkBAwkbg9U6GLkRPIFJO4 cG89WxcjF4eQwDZGiUX7jjNDOP8YJR4+n8QO4TQySvxq6WMCaWERUJWYeewsC4jNJqAu0XL0 G5gtLGAr8XrPJ1YQmxNow4ub09lBbBEBeYlvx7aC1TALREtMmnaDGcTmFbCUeLt8H5QtKPFj 8j2oGj2Jj39uM0LY4hLNrTeh4toST95dAJvPCHT291NrmCDm20lMfvCGDcLWk1h6/xFUjajE nfb1jBBvCkgs2XOeGcIWlXj5+B9YjZBAvMTXs7tZJzCKz0JyxiwkZ8xCcsYsJGcsYGRZxShW nFSUmZ5RkpuYmZNuYKSXkamXmZdasokREkeZOxiX71Q5xCjAwajEwyvBZ+AvxJpYVlyZe4hR koNJSZTXR93IX4gvKT+lMiOxOCO+qDQntfgQowQHs5II79IgQ38h3pTEyqrUonyYlAwHh5IE rzMw5oUEi1LTUyvSMnOAyQImzcTBCdLOA9TuA1LDW1yQmFucmQ6RP8UoKSXOqwSSEABJZJTm wfW+YhQHOlKYVxskywNMa3Bdr4AGMgENTGECuae4JBEhJdXAmJR3TMqPu9P8V/fi+lTtM5IV pdyd3g49fzomNYfGvXt189YcvqZn3F/LlHvMbObc+6IcnD1j16pJpxXe3NZVTO1arjlLj+Ve +5ejIip95usnhPdxNsUGPD35i/Ot+0SvvGaVbJk9+lomv7wf/z7v9nV7zP+Zf+s+vX74L4Gl +Xee1/sZC28pKrEUZyQaajEXFScCAC2yFSAoAwAA References: <12020712051780_4AE3A@oregon.uoregon.edu> Cc: Joe St Sauver , "therightkey@ietf.org" Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 07:52:51 -0000 On 7 Feb 2012, at 23:25 , Stephen Kent wrote: > federated authentication systems using certs generally seem to be > motivated because folks can make cross-certification work properly. > other federated auth systems seem to be based on having one org trust > another to assert and identity for a user know to the second, but not > the first. that's a recipe for secruity problems. Well, at the end, having an org trust another to identify a user only known= to the latter is what certificates do, don't they? The problem with federa= ted schemas is the number of potential sources of identity, that has to bec= ome unbounded by definition. You have then to rely on federation metadata, = telling you which orgs are trusted to make assertions on whom, and you need= some root(s) of trust for those metadata, metadata revocation procedures, = etc. And this collapses again into finding the-right-key(s)=85 Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx From hallam@gmail.com Wed Feb 8 05:04:09 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDC021F85EE for ; Wed, 8 Feb 2012 05:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, J_BACKHAIR_33=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90nm+jY1I9sz for ; Wed, 8 Feb 2012 05:04:08 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12E6321F8573 for ; Wed, 8 Feb 2012 05:04:04 -0800 (PST) Received: by obbwd15 with SMTP id wd15so954263obb.31 for ; Wed, 08 Feb 2012 05:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FEBz85X8BhsGjNWIp80DVRN50WIsNi+0P8K3/XhlMZI=; b=eovti/MRhXtPfz2OUtE6uVfm8qAD55skwbs9bXbimY/aR8lMyG1aQzzOEcX5e2VdJi TcsGp9LKaFWzc4mjau6XMzKonMd+rI13tKe4xY5HOJe8cNZp9CXoEro3XcGG4IQ+Gqt1 gqIUZOzc7AhTrxQRYpFB6vVREbSrtgp6fd1VE= MIME-Version: 1.0 Received: by 10.182.121.101 with SMTP id lj5mr25574855obb.39.1328706243725; Wed, 08 Feb 2012 05:04:03 -0800 (PST) Received: by 10.182.42.227 with HTTP; Wed, 8 Feb 2012 05:04:03 -0800 (PST) In-Reply-To: <201202080612.q186C7Nq003561@fs4113.wdf.sap.corp> References: <201202080612.q186C7Nq003561@fs4113.wdf.sap.corp> Date: Wed, 8 Feb 2012 08:04:03 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: joe@oregon.uoregon.edu, therightkey@ietf.org, kent@bbn.com Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 13:04:09 -0000 Yes, STARTTLS is broken in precisely the way I pointed out. BUUUUT! Now imagine that we have a mechanism that allows the mail server to state 'TLS is always offered'. The problem can be solved. On Wed, Feb 8, 2012 at 1:12 AM, Martin Rex wrote: > Phillip Hallam-Baker wrote: >> >> In practice most email that is sent encrypted is encrypted using TLS. >> If we had an infrastructure that allowed mail servers to know that >> their corresponding servers required use of TLS, the man in the middle >> downgrade attack could be defeated. > > > I'm sorry Phillip, but MTA<->MTA delivery with STARTTLS is thoroughly > broken and effectively unfixable at the moment. > > Not only is there no secure algorithm to determine which domains use > a TLS-enabled mail relay and which do not, but PKIX path validation > can not be done because plenty of mail relays are using certs that > do not validate under the (questionable) TLS X.509 PKI used by browsers, > and server endpoint validation can not be done because exactly noone > is carrying the Email domains in their SMTP Server certs for which > these servers are authorized to receive mail, and several SMTP fanciers > seem to be strongly attached to the idea that matching to the > *result* of an MX lookup rather than to the EMail target domain > would make sense security-wise (it doesn't). > > And then there are SMTP servers out there (e.g. @gmail.com), that, > while being issued by a CA that is recognized under TLS X.509 PKI > of browsers, neither matches the EMail target domain, nor does > it match the insecure target of the MX record. > > > In theory, DNSSEC could be used to solve several problems (indicating > that a domain offers STARTTLS *plus* secure identification of acceptable > MTA servers. =A0But in the near term I expect a wide adoption of DNSSEC > not more likely or faster than the wide adoption of IPv6 to solve > the IPv4 address depletion... > > > -Martin --=20 Website: http://hallambaker.com/ From kent@bbn.com Wed Feb 8 08:41:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A4021F8731 for ; Wed, 8 Feb 2012 08:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.291 X-Spam-Level: X-Spam-Status: No, score=-106.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rz5-W70BHU8g for ; Wed, 8 Feb 2012 08:41:07 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id EB3C821F872D for ; Wed, 8 Feb 2012 08:41:05 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:33044 helo=[192.67.20.202]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvAZq-000CZc-0W; Wed, 08 Feb 2012 11:41:02 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <10ED67C0-F0ED-4D2C-B897-0BE97689EDF5@tid.es> References: <12020712051780_4AE3A@oregon.uoregon.edu> <10ED67C0-F0ED-4D2C-B897-0BE97689EDF5@tid.es> Date: Wed, 8 Feb 2012 11:36:12 -0500 To: DIEGO LOPEZ GARCIA From: Stephen Kent Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: Joe St Sauver , "therightkey@ietf.org" Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 16:41:08 -0000 At 8:52 AM +0100 2/8/12, DIEGO LOPEZ GARCIA wrote: >On 7 Feb 2012, at 23:25 , Stephen Kent wrote: >> federated authentication systems using certs generally seem to be >> motivated because folks can make cross-certification work properly. >> other federated auth systems seem to be based on having one org trust >> another to assert and identity for a user know to the second, but not >> the first. that's a recipe for secruity problems. > >Well, at the end, having an org trust another to=20 >identify a user only known to the latter is what=20 >certificates do, don't they? The problem with=20 >federated schemas is the number of potential=20 >sources of identity, that has to become=20 >unbounded by definition. You have then to rely=20 >on federation metadata, telling you which orgs=20 >are trusted to make assertions on whom, and you=20 >need some root(s) of trust for those metadata,=20 >metadata revocation procedures, etc. And this=20 >collapses again into finding the-right-key(s)=8A I was a bit sloppy in my choice of words. Let me try again. In the physical world we recognize that certain=20 entities are authoritative for identifying people=20 or orgs. These entities issue credentials to=20 people and orgs, and these credentials are=20 accepted for identification and/or authorization=20 purposes, in selected contexts. If a CA issues=20 certs with IDs for which the CA is authoritative,=20 it mimics the real world model, and that's=20 generally good. In many of the federation=20 examples with which I am familiar, there is too=20 much reliance on parties to vouch for identities=20 in a nonauthoritative fashion. This is not a=20 problem for all such systems, but for many. Steve From kent@bbn.com Wed Feb 8 09:07:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1121521F8778 for ; Wed, 8 Feb 2012 09:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.307 X-Spam-Level: X-Spam-Status: No, score=-106.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQFfc3CtYdNM for ; Wed, 8 Feb 2012 09:07:06 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 05E0421F8772 for ; Wed, 8 Feb 2012 09:07:06 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:46627 helo=[192.67.20.202]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvAz2-000DMW-MB; Wed, 08 Feb 2012 12:07:04 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <008d01cce5f1$2b322f50$81968df0$@globalsign.com> References: <008d01cce5f1$2b322f50$81968df0$@globalsign.com> Date: Wed, 8 Feb 2012 11:57:23 -0500 To: "Ryan Hurst" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: 'Joe St Sauver' , therightkey@ietf.org Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 17:07:07 -0000 Ryan, That's a good list of additional problems associated with widespread use of client certs. Note that re the "branding" issue, there is a cert extension that allows for logos to be embedded in certs, although the focus for this is really server vs. client certs. Steve From kent@bbn.com Wed Feb 8 09:07:08 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001FB21F877C for ; Wed, 8 Feb 2012 09:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.322 X-Spam-Level: X-Spam-Status: No, score=-106.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3ej+j9It9mF for ; Wed, 8 Feb 2012 09:07:07 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 91FFA21F876E for ; Wed, 8 Feb 2012 09:07:06 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:46627 helo=[192.67.20.202]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvAz3-000DMW-RC; Wed, 08 Feb 2012 12:07:06 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> Date: Wed, 8 Feb 2012 12:06:55 -0500 To: Phillip Hallam-Baker From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 17:07:08 -0000 At 6:52 PM -0500 2/7/12, Phillip Hallam-Baker wrote: >... > >The reason I no longer believe in end-to-end solutions is that the >endpoint for a public key is always a machine and the desired endpoint >is a person. yes, the machine is the endpoint, but machines are always in the loop for the sorts of transactions we're discussing, unless we're very restrictive. The EU-inspired PIN pad + display that shows the user a number representing a value being authorized by a sig is an exception.) So, I don't agree that the distinction between the user and a machine operated by a user is really significant, in the end. (Yes, I am ware of the many security problems that arise because the user doesn't really know what the code is doing, but nothing is perfect.) >... > >Any scheme that does not take account of the fact that a user must be >able to access their account from at lest fifteen different devices, >some of which will be mobile and possibly lost is useless in the real >world. The military can tollerate such systems because they will order >people to use them. I agree that credential portability is essential. BTW, the US DoD operates more like a company with an eye on the bottom line than a monolithic security-focused organization, as you suggest above :-). >S/MIME with a private key shared to fifteen devices no longer looks >very secure to me. Crednetial portability does not necessarily imply a private key kept in SW in every device. Steve From ryan.hurst@globalsign.com Wed Feb 8 09:18:16 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67AF421F8543 for ; Wed, 8 Feb 2012 09:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBs5NTD9yBO5 for ; Wed, 8 Feb 2012 09:18:15 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD61821F85F6 for ; Wed, 8 Feb 2012 09:18:15 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so795252pbc.31 for ; Wed, 08 Feb 2012 09:18:15 -0800 (PST) Received: by 10.68.218.202 with SMTP id pi10mr50431010pbc.16.1328721495334; Wed, 08 Feb 2012 09:18:15 -0800 (PST) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id t10sm4511502pbb.18.2012.02.08.09.18.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 09:18:14 -0800 (PST) From: "Ryan Hurst" To: "'Stephen Kent'" References: <008d01cce5f1$2b322f50$81968df0$@globalsign.com> In-Reply-To: Date: Wed, 8 Feb 2012 09:18:12 -0800 Message-ID: <07b401cce685$a38fc950$eaaf5bf0$@globalsign.com> X-Mailer: Microsoft Outlook 14.0 MIME-Version: 1.0 Thread-Index: AQL4mjWmSaqaob+72JTbo+7ebzds9wHL3Fsvk812BFA= Content-Language: en-us Content-Type: multipart/signed; boundary="----=_NextPart_000_07AF_01CCE642.94B59560"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Cc: 'Joe St Sauver' , therightkey@ietf.org Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 17:18:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07AF_01CCE642.94B59560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Steve, Thank you. I actually contributed to RFC 3709 and I believe made Windows the first platform to support it, that said the branding element I am referring to in this case is different. When designing a user experience one picks colors, typefaces, layout and workflow; for example consider Coke "red" and type typical Coke typography; if the authentication experience is not consistent with the design goals of a site adoption will only happen when security is seen more important that design and ease of use. As long as that is the case in this world of consumerization of IT I don't expect client certificates to be used outside of closed communities. Ryan -----Original Message----- From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Wednesday, February 08, 2012 8:57 AM To: Ryan Hurst Cc: 'Joe St Sauver'; therightkey@ietf.org Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) Ryan, That's a good list of additional problems associated with widespread use of client certs. Note that re the "branding" issue, there is a cert extension that allows for logos to be embedded in certs, although the focus for this is really server vs. client certs. Steve _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey ------=_NextPart_000_07AF_01CCE642.94B59560 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCCA3Uw ggJdoAMCAQICCwQAAAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3O o+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsurHExwB6E9 CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8GPIhpWypNxadU uGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounICjjr8iQTT3NUkxOF Ohu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjIGSvRRqpI1mQq14M0/ywq wWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEB ANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16qEUi25Qijs8o9YU3TRgmzPsOg42NVG/K6 76054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeYBN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8s uWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUMHaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRW MZXQZ4mFK/lspl1GnQyqguSZUd1wt9tWPWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY 24GzBBzFH6SAbxUgyd4MiAod1mZV4vxIySkmaeAwggQWMIIC/qADAgECAgsEAAAAAAEvTuEvUjAN BgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQ MA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTExMDQxMzEw MDAwMFoXDTE5MDQxMzEwMDAwMFowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFrQfk17PgSfd0iUWlft7kTRid3FDvjE4FvPuR0F34M tfQs5AyNU9TcMCAov26OEf5mEeRRFsfdf/3hNBJQv/PYmOxpC9LQ2rJlceEzl566q7M4lHMRDz6h 0RPMeDYbQSu/vKNJ7DCCTANYMmdhQOU6NhMNQQbr6L7wyfjbmt6jgjQTbvvAPnjaSZVZ5bv6ge/l 1mj17VDJbCIpMQ/oERBVVIGBOFcwbi2tpJINFS3dPV5BNnHkQ5umIEQE7g5OqIFMl+Di8QhiCRfM oumd+zNMHpgwOlH39BLqncA0HeR8Bv63q51I7dYKy3QMavAcMsEUYNHhR5hPkoYacjtxYvsCAwEA AaOB5TCB4jAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUPxXS bXwv5zGeQwoGqJRsLDvF7mUwRwYDVR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBz Oi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC5jcmwwHwYDVR0jBBgwFoAUYHtmGkUNl8qJUC99BM00 qP/8/UswDQYJKoZIhvcNAQEFBQADggEBAENzecykzEkxAxxhQIHf4LvdSm/AMTx4I6vu3YX+5pAo pzKqqy2otlzq8/Aj+twT2gMe6BjlASNDMgEgRpOc3o/S96B7YhdgS9NZtbAZ0/K0MU9giXf/o6o1 JdKdnsPE9x0smra7KKBrw8H9NMggdiR0zb7UMTTvLesf/tOPANUPtIu7n9J058qyS4w9OM4S/Pcr XrWbKZbTqSVWG5sIhY6uj8bHVDbYVA5nv/aTi5ig50FNKVvyRMC7Nk2AgTSsHYEhgJPP8/rNkgpb SiBtFIeVOreo+yT7sDT/85yJsDK5RwydWKVtK5Bdjxq2lQoAwX/XTgfiCKZ8B3yIviw/niEwggUG MIID7qADAgECAhIRIW+uNPxdwlMR7qsGU+m0guUwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29u YWxTaWduIDIgQ0EgLSBHMjAeFw0xMjAxMjMxNjM2NTlaFw0xNTAxMjMxNjM2NTlaMIGUMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTmV3IEhhbXNwaGlyZTETMBEGA1UEBxMKUG9ydHNtb3V0aDEZMBcG A1UEChMQR2xvYmFsU2lnbiwgSW5jLjETMBEGA1UEAxMKUnlhbiBIdXJzdDEoMCYGCSqGSIb3DQEJ ARYZcnlhbi5odXJzdEBnbG9iYWxzaWduLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALgBJJO9q+awVAChvrS6RJLA4Av2dP+z32W01QIB/l88fmM1x4wrFpCx7aaI6ZFEhdrKRyrW n9NsjvRm1x7fyvaZs7CoMcc9WLXcbEkTJRdaBpEG14My7k4bJY0bWRyFWwZaluy1PRni/SZ3mbUF gWfEHbR5snI5HaVcPGwUrbyecpX7l4yPvpTwGk9DhIIfvJMwbrLRdewHdwKsEqvajdM5iAQq/6g2 dtqgy3dTEy32dJ/2PIiyGOp+dPkB7DcJQ0xq07nmDkVdd0i6QDB6DVhJvWWzTmpbexbTRPd3t1Cz 3/s27EKD8DZ6WZUlKjLz4wtHwlIUR/9oyCM79PIuD+MCAwEAAaOCAY8wggGLMA4GA1UdDwEB/wQE AwIFoDBNBgNVHSAERjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cu Z2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wJAYDVR0RBB0wG4EZcnlhbi5odXJzdEBnbG9iYWxz aWduLmNvbTAJBgNVHRMEAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8E PDA6MDigNqA0hjJodHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMmcy LmNybDBVBggrBgEFBQcBAQRJMEcwRQYIKwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2ln bi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMmcyLmNydDAdBgNVHQ4EFgQUVaIQJ7T8vvZ5Vipx ZictXpJKPOEwHwYDVR0jBBgwFoAUPxXSbXwv5zGeQwoGqJRsLDvF7mUwDQYJKoZIhvcNAQEFBQAD ggEBACFCLqEs9652Z/cgEXggPMK9EjQVph0Ep+mtKT8fQ8N5ri+mwttakDS3RJqKOIli3EqOUzhs 937ZyFvt6Nq0N3KtkjOYNXKrhzfT/EyeKcYqiSlgDXX9V76LZ2+O6W7rmpqyu1BEbJsC65nruWun 8rc4wWCNXk0LcAdgvO81TgPBzhBDUFow6DorNhKspsAFFlqN+ukL26J4+y/uYMhcvH+2gE/FY2Vr m8mbkOtl2fu4d28EITqQzKRs4s3mmYQrRQiXAqHpCLlcPSnOVWQRmWIWQEwmC5t394XvF6DtMo9Y LnHI4Wn1J0yiUkzstMLfCdI7d+sEB6/6r+caz1fHK+wxggOYMIIDlAIBATBqMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNv bmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TAJBgUrDgMCGgUAoIICAzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAyMDgxNzE4MTJaMCMGCSqG SIb3DQEJBDEWBBQ2gmNRlhIBKNKj5b1RIHmI2WAJtjB5BgkrBgEEAYI3EAQxbDBqMFQxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBl cnNvbmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TB7BgsqhkiG9w0BCRACCzFs oGowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUds b2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMIGrBgkq hkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglg hkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3 DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0G CSqGSIb3DQEBAQUABIIBAKGfohqsu0skln4DiDuwfSPUowuo6CqiFUd7Lwu6uTs3GlsraS79oj7M kNKaJxcRT6rxtGaLTIF/r/+J2Bgn7RYH7gQMf30G2ihExAQF8WnXuTH7dqjAn6n9Wn1HoYMTay1y GdmcgKzEPzzelEKBA6U/rkzFCT+h9UH6jBUM+tOhsfqd9krGc6Bmt7B/61kju/AfpGayLEX9kns7 CBdbOBO3yGFtPvB26ak3H+Lr3YHE0wjKt5ojmqAoEZGK1ylY4CXr8mN5FlScHOrBGyveQI9BLgyh 6oHmECUcCBRhvDALNE35an0rFjdI1n6A1KSayy3tz4UYqQHLvW3J9RVvcQ4AAAAAAAA= ------=_NextPart_000_07AF_01CCE642.94B59560-- From benl@google.com Wed Feb 8 09:49:17 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD3C21F85CF for ; Wed, 8 Feb 2012 09:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2HmclfM4WLk for ; Wed, 8 Feb 2012 09:49:17 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EAFF721F85CC for ; Wed, 8 Feb 2012 09:49:16 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so819946pbc.31 for ; Wed, 08 Feb 2012 09:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type; bh=0/IMWlp4N+81GUWMLR4k8R0CHRjKcF8GjOQ3F4T0Nho=; b=mLVVmngscpfJzao/tDnQJxt80t13A8nJhGGLx2IHIFFGbzg9zajeFgtdXJsaQOlX87 AvDjK+xqIfay725JEQl8v+2k21ADbhtPehgfA+RO6nhzQnfh1kVMVY/Lh0P7vbOxBGHx V0MncU0yhmRMqgELPPENzwty0QwY0Uj0ITE4Y= Received: by 10.68.228.137 with SMTP id si9mr19999797pbc.24.1328723356694; Wed, 08 Feb 2012 09:49:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.228.137 with SMTP id si9mr19999730pbc.24.1328723356289; Wed, 08 Feb 2012 09:49:16 -0800 (PST) Received: by 10.142.8.10 with HTTP; Wed, 8 Feb 2012 09:49:16 -0800 (PST) In-Reply-To: <07b401cce685$a38fc950$eaaf5bf0$@globalsign.com> References: <008d01cce5f1$2b322f50$81968df0$@globalsign.com> <07b401cce685$a38fc950$eaaf5bf0$@globalsign.com> Date: Wed, 8 Feb 2012 17:49:16 +0000 Message-ID: From: Ben Laurie To: Ryan Hurst X-System-Of-Record: true Content-Type: multipart/alternative; boundary=047d7b2ee031a80c8404b8778391 Cc: Joe St Sauver , therightkey@ietf.org, Stephen Kent Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 17:49:17 -0000 --047d7b2ee031a80c8404b8778391 Content-Type: text/plain; charset=ISO-8859-1 On 8 February 2012 17:18, Ryan Hurst wrote: > Steve, > > Thank you. > > I actually contributed to RFC 3709 and I believe made Windows the first > platform to support it, that said the branding element I am referring to in > this case is different. > > When designing a user experience one picks colors, typefaces, layout and > workflow; for example consider Coke "red" and type typical Coke typography; > if the authentication experience is not consistent with the design goals of > a site adoption will only happen when security is seen more important that > design and ease of use. > > As long as that is the case in this world of consumerization of IT I don't > expect client certificates to be used outside of closed communities. > Client certs do not need to interfere with the branding experience. For example, http://www.browserauth.net/ shows how to use them without touching the site's ability to fully control the user experience. > > Ryan > > -----Original Message----- > From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org] > On > Behalf Of Stephen Kent > Sent: Wednesday, February 08, 2012 8:57 AM > To: Ryan Hurst > Cc: 'Joe St Sauver'; therightkey@ietf.org > Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the > real RPF please stand up?) > > Ryan, > > That's a good list of additional problems associated with widespread use of > client certs. > > Note that re the "branding" issue, there is a cert extension that allows > for > logos to be embedded in certs, although the focus for this is really server > vs. client certs. > > Steve > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > > --047d7b2ee031a80c8404b8778391 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 8 February 2012 17:18, Ryan Hurst <ryan.hurst@= globalsign.com> wrote:
Steve,

Thank you.

I actually contributed to RFC 3709 and I believe made Windows the first
platform to support it, that said the branding element I am referring to in=
this case is different.

When designing a user experience one picks colors, typefaces, layout and workflow; for example consider Coke "red" and type typical Coke t= ypography;
if the authentication experience is not consistent with the design goals of=
a site adoption will only happen when security is seen more important that<= br> design and ease of use.

As long as that is the case in this world of consumerization of IT I don= 9;t
expect client certificates to be used outside of closed communities.

Client certs do not need to interfere with th= e branding experience.

For example, http://www.browserauth.net/ shows how to use = them without touching the site's ability to fully control the user expe= rience.
=A0

Ryan

-----Original Message-----
From: therightkey-bounces@i= etf.org [mailto:therigh= tkey-bounces@ietf.org] On
Behalf Of Stephen Kent
Sent: Wednesday, February 08,= 2012 8:57 AM
To: Ryan Hurst
Cc: 'Joe St Sauver'; therig= htkey@ietf.org
Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?)

Ryan,

That's a good list of additional problems associated with widespread us= e of
client certs.

Note that re the "branding" issue, there is a cert extension that= allows for
logos to be embedded in certs, although the focus for this is really server=
vs. client certs.

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

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


--047d7b2ee031a80c8404b8778391-- From ryan.hurst@globalsign.com Wed Feb 8 10:50:05 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AB921F8629 for ; Wed, 8 Feb 2012 10:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPjnykI1+SEi for ; Wed, 8 Feb 2012 10:50:02 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5704021F85FC for ; Wed, 8 Feb 2012 10:50:02 -0800 (PST) Received: by dakl33 with SMTP id l33so786965dak.31 for ; Wed, 08 Feb 2012 10:50:02 -0800 (PST) Received: by 10.68.228.198 with SMTP id sk6mr41798533pbc.9.1328727001319; Wed, 08 Feb 2012 10:50:01 -0800 (PST) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id w4sm326292pbf.4.2012.02.08.10.49.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 10:50:00 -0800 (PST) From: "Ryan Hurst" To: "'Ben Laurie'" References: <008d01cce5f1$2b322f50$81968df0$@globalsign.com> <07b401cce685$a38fc950$eaaf5bf0$@globalsign.com> In-Reply-To: Date: Wed, 8 Feb 2012 10:49:59 -0800 Message-ID: <087101cce692$75ca07d0$615e1770$@globalsign.com> X-Mailer: Microsoft Outlook 14.0 MIME-Version: 1.0 Thread-Index: AQL4mjWmSaqaob+72JTbo+7ebzds9wGmTpSgASWWThUBSY1IVJO7QLZg Content-Language: en-us Content-Type: multipart/signed; boundary="----=_NextPart_000_0869_01CCE64F.66E4FE70"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Cc: 'Joe St Sauver' , therightkey@ietf.org, 'Stephen Kent' Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:50:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0869_01CCE64F.66E4FE70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_086A_01CCE64F.66E4FE70" ------=_NextPart_001_086A_01CCE64F.66E4FE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ben - I am familiar with Google's Origin Bound Certificate (OBC) work, it in many respects is similar to the BrowserID proposal; and you are right that this happens at a layer below the user experience if there is no pin/password protecting the key. That said, unless something has changed recently (I have spent the last few years focusing on securing ad networks) since it's done as part of the TLS negotiation the authentication is persisted in the TLS session cache meaning a mechanism is still needed to "log-out" or "reset that session" and I don't believe one exists today. One problem I have with both BrowserID and OBC is that they don't really solve the initial authentication problem, this is true to a lesser extent for BrowserID because at least until recently they didn't even have a concept of a password. But as I understand OBC initial authentication happens via a traditional methods (aka passwords) and it is persisted via the "origin certificates"; this approach is better cryptographically than BrowserID in that you get the cryptographic binding of user authentication to the session-plus today BrowserID relies on Javascript based cryptography implementations which has a ton of shortcomings. With that said, on the surface OBC feels like it's not really trying to address authentication but a gap in cryptographic cookie support. One of the things I like about BrowserID as an approach is that I agree with others that the portability of key material in today's world is important and by them including the vetting of the ownership of an email in their key provisioning workflow they kind of address this problem. To be clear I am a fan of anything that moves the ball forward here, though I really wish as an industry we could align behind a problem statement and work towards it together instead of having so many competing approaches but it is human nature ;) Ryan From: Ben Laurie [mailto:benl@google.com] Sent: Wednesday, February 08, 2012 9:49 AM To: Ryan Hurst Cc: Stephen Kent; Joe St Sauver; therightkey@ietf.org Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) On 8 February 2012 17:18, Ryan Hurst wrote: Steve, Thank you. I actually contributed to RFC 3709 and I believe made Windows the first platform to support it, that said the branding element I am referring to in this case is different. When designing a user experience one picks colors, typefaces, layout and workflow; for example consider Coke "red" and type typical Coke typography; if the authentication experience is not consistent with the design goals of a site adoption will only happen when security is seen more important that design and ease of use. As long as that is the case in this world of consumerization of IT I don't expect client certificates to be used outside of closed communities. Client certs do not need to interfere with the branding experience. For example, http://www.browserauth.net/ shows how to use them without touching the site's ability to fully control the user experience. Ryan -----Original Message----- From: therightkey-bounces@ietf.org [mailto:therightkey-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Wednesday, February 08, 2012 8:57 AM To: Ryan Hurst Cc: 'Joe St Sauver'; therightkey@ietf.org Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) Ryan, That's a good list of additional problems associated with widespread use of client certs. Note that re the "branding" issue, there is a cert extension that allows for logos to be embedded in certs, although the focus for this is really server vs. client certs. Steve _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey ------=_NextPart_001_086A_01CCE64F.66E4FE70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ben –

 

I am familiar with Google’s Origin Bound Certificate (OBC) = work, it in many respects is similar to the BrowserID proposal; and you = are right that this happens at a layer below the user experience if = there is no pin/password protecting the key.

 

That said, unless something has changed recently (I have spent the = last few years focusing on securing ad networks) since it’s done = as part of the TLS negotiation the authentication is persisted in the = TLS session cache meaning a mechanism is still needed to = “log-out” or “reset that session” and I = don’t believe one exists today.

 

One problem I have with both BrowserID and OBC is that they = don’t really solve the initial authentication problem, this is = true to a lesser extent for BrowserID because at least until recently = they didn’t even have a concept of a = password.

 

But as I understand OBC initial authentication happens via a = traditional methods (aka passwords) and it is persisted via the = “origin certificates”; this approach is better = cryptographically than BrowserID in that you get the cryptographic = binding of user authentication to the session—plus today BrowserID = relies on Javascript based cryptography implementations which has a ton = of shortcomings.

 

With that said, on the surface OBC feels like it’s not really = trying to address authentication but a gap in cryptographic cookie = support.

 

One of the things I like about BrowserID as an approach is that I = agree with others that the portability of key material in today’s = world is important and by them including the vetting of the ownership of = an email in their key provisioning workflow they kind of address this = problem.

 

To be clear I am a fan of anything that moves the ball forward here, = though I really wish as an industry we could align behind a problem = statement and work towards it together instead of having so many = competing approaches but it is human nature ;)

 

Ryan

 

 

From:= = Ben Laurie [mailto:benl@google.com]
Sent: Wednesday, February = 08, 2012 9:49 AM
To: Ryan Hurst
Cc: Stephen Kent; = Joe St Sauver; therightkey@ietf.org
Subject: Re: [therightkey] = Client Certificate Usability (was RE: Will the real RPF please stand = up?)

 

 

On 8 February 2012 17:18, Ryan Hurst <ryan.hurst@globalsign.com&g= t; wrote:

Steve,

Thank = you.

I actually contributed to RFC 3709 and I believe made = Windows the first
platform to support it, that said the branding = element I am referring to in
this case is different.

When = designing a user experience one picks colors, typefaces, layout = and
workflow; for example consider Coke "red" and type = typical Coke typography;
if the authentication experience is not = consistent with the design goals of
a site adoption will only happen = when security is seen more important that
design and ease of = use.

As long as that is the case in this world of consumerization = of IT I don't
expect client certificates to be used outside of closed = communities.

 

Client certs do not need to interfere with the = branding experience.

 

For example, http://www.browserauth.net/ = shows how to use them without touching the site's ability to fully = control the user experience.

 


Ryan

-----Original Message-----
From: therightkey-bounces@ietf.org= [mailto:therightkey-bounces@ietf.org= ] On
Behalf Of Stephen Kent

Sent: Wednesday, February 08, 2012 8:57 AM
To: Ryan = Hurst
Cc: 'Joe St Sauver'; therightkey@ietf.org
Subject:= Re: [therightkey] Client Certificate Usability (was RE: Will = the
real RPF please stand up?)

Ryan,

That's a good list = of additional problems associated with widespread use of
client = certs.

Note that re the "branding" issue, there is a = cert extension that allows for
logos to be embedded in certs, = although the focus for this is really server
vs. client = certs.

Steve
_______________________________________________therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey


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

 

------=_NextPart_001_086A_01CCE64F.66E4FE70-- ------=_NextPart_000_0869_01CCE64F.66E4FE70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCCA3Uw ggJdoAMCAQICCwQAAAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3O o+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsurHExwB6E9 CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8GPIhpWypNxadU uGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounICjjr8iQTT3NUkxOF Ohu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjIGSvRRqpI1mQq14M0/ywq wWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEB ANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16qEUi25Qijs8o9YU3TRgmzPsOg42NVG/K6 76054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeYBN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8s uWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUMHaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRW MZXQZ4mFK/lspl1GnQyqguSZUd1wt9tWPWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY 24GzBBzFH6SAbxUgyd4MiAod1mZV4vxIySkmaeAwggQWMIIC/qADAgECAgsEAAAAAAEvTuEvUjAN BgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQ MA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTExMDQxMzEw MDAwMFoXDTE5MDQxMzEwMDAwMFowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFrQfk17PgSfd0iUWlft7kTRid3FDvjE4FvPuR0F34M tfQs5AyNU9TcMCAov26OEf5mEeRRFsfdf/3hNBJQv/PYmOxpC9LQ2rJlceEzl566q7M4lHMRDz6h 0RPMeDYbQSu/vKNJ7DCCTANYMmdhQOU6NhMNQQbr6L7wyfjbmt6jgjQTbvvAPnjaSZVZ5bv6ge/l 1mj17VDJbCIpMQ/oERBVVIGBOFcwbi2tpJINFS3dPV5BNnHkQ5umIEQE7g5OqIFMl+Di8QhiCRfM oumd+zNMHpgwOlH39BLqncA0HeR8Bv63q51I7dYKy3QMavAcMsEUYNHhR5hPkoYacjtxYvsCAwEA AaOB5TCB4jAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUPxXS bXwv5zGeQwoGqJRsLDvF7mUwRwYDVR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBz Oi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC5jcmwwHwYDVR0jBBgwFoAUYHtmGkUNl8qJUC99BM00 qP/8/UswDQYJKoZIhvcNAQEFBQADggEBAENzecykzEkxAxxhQIHf4LvdSm/AMTx4I6vu3YX+5pAo pzKqqy2otlzq8/Aj+twT2gMe6BjlASNDMgEgRpOc3o/S96B7YhdgS9NZtbAZ0/K0MU9giXf/o6o1 JdKdnsPE9x0smra7KKBrw8H9NMggdiR0zb7UMTTvLesf/tOPANUPtIu7n9J058qyS4w9OM4S/Pcr XrWbKZbTqSVWG5sIhY6uj8bHVDbYVA5nv/aTi5ig50FNKVvyRMC7Nk2AgTSsHYEhgJPP8/rNkgpb SiBtFIeVOreo+yT7sDT/85yJsDK5RwydWKVtK5Bdjxq2lQoAwX/XTgfiCKZ8B3yIviw/niEwggUG MIID7qADAgECAhIRIW+uNPxdwlMR7qsGU+m0guUwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29u YWxTaWduIDIgQ0EgLSBHMjAeFw0xMjAxMjMxNjM2NTlaFw0xNTAxMjMxNjM2NTlaMIGUMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTmV3IEhhbXNwaGlyZTETMBEGA1UEBxMKUG9ydHNtb3V0aDEZMBcG A1UEChMQR2xvYmFsU2lnbiwgSW5jLjETMBEGA1UEAxMKUnlhbiBIdXJzdDEoMCYGCSqGSIb3DQEJ ARYZcnlhbi5odXJzdEBnbG9iYWxzaWduLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALgBJJO9q+awVAChvrS6RJLA4Av2dP+z32W01QIB/l88fmM1x4wrFpCx7aaI6ZFEhdrKRyrW n9NsjvRm1x7fyvaZs7CoMcc9WLXcbEkTJRdaBpEG14My7k4bJY0bWRyFWwZaluy1PRni/SZ3mbUF gWfEHbR5snI5HaVcPGwUrbyecpX7l4yPvpTwGk9DhIIfvJMwbrLRdewHdwKsEqvajdM5iAQq/6g2 dtqgy3dTEy32dJ/2PIiyGOp+dPkB7DcJQ0xq07nmDkVdd0i6QDB6DVhJvWWzTmpbexbTRPd3t1Cz 3/s27EKD8DZ6WZUlKjLz4wtHwlIUR/9oyCM79PIuD+MCAwEAAaOCAY8wggGLMA4GA1UdDwEB/wQE AwIFoDBNBgNVHSAERjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cu Z2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wJAYDVR0RBB0wG4EZcnlhbi5odXJzdEBnbG9iYWxz aWduLmNvbTAJBgNVHRMEAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8E PDA6MDigNqA0hjJodHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMmcy LmNybDBVBggrBgEFBQcBAQRJMEcwRQYIKwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2ln bi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMmcyLmNydDAdBgNVHQ4EFgQUVaIQJ7T8vvZ5Vipx ZictXpJKPOEwHwYDVR0jBBgwFoAUPxXSbXwv5zGeQwoGqJRsLDvF7mUwDQYJKoZIhvcNAQEFBQAD ggEBACFCLqEs9652Z/cgEXggPMK9EjQVph0Ep+mtKT8fQ8N5ri+mwttakDS3RJqKOIli3EqOUzhs 937ZyFvt6Nq0N3KtkjOYNXKrhzfT/EyeKcYqiSlgDXX9V76LZ2+O6W7rmpqyu1BEbJsC65nruWun 8rc4wWCNXk0LcAdgvO81TgPBzhBDUFow6DorNhKspsAFFlqN+ukL26J4+y/uYMhcvH+2gE/FY2Vr m8mbkOtl2fu4d28EITqQzKRs4s3mmYQrRQiXAqHpCLlcPSnOVWQRmWIWQEwmC5t394XvF6DtMo9Y LnHI4Wn1J0yiUkzstMLfCdI7d+sEB6/6r+caz1fHK+wxggOYMIIDlAIBATBqMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNv bmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TAJBgUrDgMCGgUAoIICAzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAyMDgxODQ5NThaMCMGCSqG SIb3DQEJBDEWBBQDweCKHHzCdtfMfJ8txxBWD77GSDB5BgkrBgEEAYI3EAQxbDBqMFQxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBl cnNvbmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TB7BgsqhkiG9w0BCRACCzFs oGowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUds b2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMIGrBgkq hkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglg hkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3 DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0G CSqGSIb3DQEBAQUABIIBABKJ8vFHWdyn0hjuutA16Nmt4yr01NtgraMzqbn4I3mnFukvZwYjjofK 8ILf5eZkj1Oe41tMGfb/UYt2Lk9S7K1GTXBGU8FE6W76hiZXvdhkNYfxWLixhBqY3LhYC1XEfztz J1ZmIZTKnwwNbL07v6wS44jirrFTOFFNYSefAzX5m8zsA0qcbolwhgcyrT4dcxF79K+iTRxL08Vx wl+0K30W4zNa18h6cYxuDbZmPqHLtT5L3FC7DyM0Y5IRCBjliVlC6qJhL05kyat/WasI8d9eKcVJ yhawLa04HR5/BeUOBQbOd30uWChiTEl0oezZb9CkylpY9+6tuh8+sBazcAAAAAAAAAA= ------=_NextPart_000_0869_01CCE64F.66E4FE70-- From diego@tid.es Wed Feb 8 10:56:17 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026E521F85F6 for ; Wed, 8 Feb 2012 10:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.316 X-Spam-Level: X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyYWZC1SxEKz for ; Wed, 8 Feb 2012 10:56:16 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED83F21F8552 for ; Wed, 8 Feb 2012 10:56:15 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ3003AS8LQ1J@tid.hi.inet> for therightkey@ietf.org; Wed, 08 Feb 2012 19:56:14 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id B6.3E.02893.E45C23F4; Wed, 08 Feb 2012 19:56:14 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LZ3003AN8LQ1J@tid.hi.inet> for therightkey@ietf.org; Wed, 08 Feb 2012 19:56:14 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Wed, 08 Feb 2012 19:56:14 +0100 Date: Wed, 08 Feb 2012 19:56:13 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: Stephen Kent Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [therightkey] Will the real RPF please stand up? Thread-index: Aczmk1Q1I+7LeDsdQcuqXhT+E9HI6A== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f2d6d000000b4d-ca-4f32c54e0aac X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsXCFe/Apet31Mjf4OBOWYuPF36yODB6LFny kymAMYrLJiU1J7MstUjfLoErY9ruaSwFU3grpr/dztzAeJmri5GTQ0LARGJVx0N2CFtM4sK9 9WxdjFwcQgIbGCXm/33PDuH8Y5RY0HGMCcJpZJRYdGIBC0gLi4CqxPdti1hBbDYBdYmWo9/A 4sICthKv93wCi3MCrbj07CQjiC0iIC/x7dhWsBpmgWiJSdNuMIPYvAKWEpuPfGODsAUlfky+ B1WjJ/Hxz21GCFtcorn1JlRcW+LJuwtg8xmBzv5+ag0TxHw7ickP3gDN4QCy9ST+7AiCKBGV uNO+nhHiSwGJJXvOM0PYohIvH/9jhfhrJ6PE97WNzBMYxWchOWMWkjNmITljFpIzFjCyrGIU K04qykzPKMlNzMxJNzDUy8jUy8xLLdnECImkjB2My3eqHGIU4GBU4uFtOGjkL8SaWFZcmXuI UZKDSUmU9/BhoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3tpNQDnelMTKqtSifJiUDAeHkgTv wSNAKcGi1PTUirTMHGC6gEkzcXCCtPMAtT8CqeEtLkjMLc5Mh8ifYlTl+Hzq83lGIZa8/LxU KXHevSBFAiBFGaV5cHNeMYoDHSzMex4kywNMeHATXgENZwIansJkCDK8JBEhJdXA6LssY25q cP7qyOki6h+WT/f4t52pWH8ed9FvJdG+GdUSCXuMllitn2Dp+uGd8ITfNafUpapnft8eckg0 XT/nXvBEMbXDnse2nJI45vv++DE328mrV+1MDkju/hJXwyh9vqWubc7EPTNWRdxYldMns+nI UVmed3pW1/b+8tjbvqDYa//smfGZj5RYijMSDbWYi4oTAYnc33w1AwAA References: <12020712051780_4AE3A@oregon.uoregon.edu> <10ED67C0-F0ED-4D2C-B897-0BE97689EDF5@tid.es> Cc: Joe St Sauver , "therightkey@ietf.org" Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:56:17 -0000 On 8 Feb 2012, at 17:36 , Stephen Kent wrote: > In the physical world we recognize that certain > entities are authoritative for identifying people > or orgs. These entities issue credentials to > people and orgs, and these credentials are > accepted for identification and/or authorization > purposes, in selected contexts. If a CA issues > certs with IDs for which the CA is authoritative, > it mimics the real world model, and that's > generally good. In many of the federation > examples with which I am familiar, there is too > much reliance on parties to vouch for identities > in a nonauthoritative fashion. This is not a > problem for all such systems, but for many. I won't argue your point, but let me insist that is rather a matter of comm= on practices in identity vetting than of the architectures or technologies = themselves. CAs can as lax as the sloppiest federated identity provider, an= d conversely a federation can require its participating identity providers = to apply procedures as strict as the ones used by top-level CAs. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx From benl@google.com Wed Feb 8 11:19:53 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29D421F854D for ; Wed, 8 Feb 2012 11:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl2BmB0qgVus for ; Wed, 8 Feb 2012 11:19:52 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9146C21F8546 for ; Wed, 8 Feb 2012 11:19:52 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so889309pbc.31 for ; Wed, 08 Feb 2012 11:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type; bh=01dpdv16UFE2IqZXJD8/hA8X5b/731MQlm6LWt6AZzs=; b=06fkvCXTl40C/BF2xVbo6xxaoH37DOUEVn1P9unocNd/VOPGKHmZfl3oY2P4UT5iRh oixr32LPqhSg1oc20MU8kLGQkdSOGNWh7YbJvKrd7wh/YVze6uljYsS5JkVr7XY7E6NE OanicZtKZ1pxNw5zG+xaXPyzVuv9SCisJmlcw= Received: by 10.68.74.41 with SMTP id q9mr52212888pbv.92.1328728792351; Wed, 08 Feb 2012 11:19:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.41 with SMTP id q9mr52212668pbv.92.1328728790874; Wed, 08 Feb 2012 11:19:50 -0800 (PST) Received: by 10.142.8.10 with HTTP; Wed, 8 Feb 2012 11:19:50 -0800 (PST) In-Reply-To: <087101cce692$75ca07d0$615e1770$@globalsign.com> References: <008d01cce5f1$2b322f50$81968df0$@globalsign.com> <07b401cce685$a38fc950$eaaf5bf0$@globalsign.com> <087101cce692$75ca07d0$615e1770$@globalsign.com> Date: Wed, 8 Feb 2012 19:19:50 +0000 Message-ID: From: Ben Laurie To: Ryan Hurst X-System-Of-Record: true Content-Type: multipart/alternative; boundary=f46d040f9c9c95395404b878c76b Cc: Joe St Sauver , therightkey@ietf.org, Stephen Kent Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 19:19:53 -0000 --f46d040f9c9c95395404b878c76b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 8 February 2012 18:49, Ryan Hurst wrote: > One of the things I like about BrowserID as an approach is that I agree > with others that the portability of key material in today=92s world is > important and by them including the vetting of the ownership of an email = in > their key provisioning workflow they kind of address this problem. > Then you might like the work I did on portability of key material: http://www.links.org/files/nigori-overview.pdf. There's also a detailed spec and code. --f46d040f9c9c95395404b878c76b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 8 February 2012 18:49, Ryan Hurst <ryan.hurst@= globalsign.com> wrote:

One of the things I like about BrowserID as an approach is that= I agree with others that the portability of key material in today=92s worl= d is important and by them including the vetting of the ownership of an ema= il in their key provisioning workflow they kind of address this problem.


Then you might like the work I= did on portability of key material: http://www.links.org/files/nigori-overview.pdf.

There's also a detailed spec and code.
--f46d040f9c9c95395404b878c76b-- From kent@bbn.com Wed Feb 8 12:03:24 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0AC11E80AF for ; Wed, 8 Feb 2012 12:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.347 X-Spam-Level: X-Spam-Status: No, score=-106.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AC5I-NTCuFsZ for ; Wed, 8 Feb 2012 12:03:23 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 98E5111E80AE for ; Wed, 8 Feb 2012 12:03:23 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:57560 helo=[192.67.20.202]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvDjc-000Ixx-36; Wed, 08 Feb 2012 15:03:20 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <10ED67C0-F0ED-4D2C-B897-0BE97689EDF5@tid.es> Date: Wed, 8 Feb 2012 14:30:29 -0500 To: DIEGO LOPEZ GARCIA From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Joe St Sauver , "therightkey@ietf.org" Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:03:24 -0000 At 7:56 PM +0100 2/8/12, DIEGO LOPEZ GARCIA wrote: >On 8 Feb 2012, at 17:36 , Stephen Kent wrote: >> In the physical world we recognize that certain >> entities are authoritative for identifying people >> or orgs. These entities issue credentials to >> people and orgs, and these credentials are >> accepted for identification and/or authorization >> purposes, in selected contexts. If a CA issues >> certs with IDs for which the CA is authoritative, >> it mimics the real world model, and that's >> generally good. In many of the federation >> examples with which I am familiar, there is too >> much reliance on parties to vouch for identities >> in a nonauthoritative fashion. This is not a >> problem for all such systems, but for many. > >I won't argue your point, but let me insist that is rather a matter >of common practices in identity vetting than of the architectures or >technologies themselves. CAs can as lax as the sloppiest federated >identity provider, and conversely a federation can require its >participating identity providers to apply procedures as strict as >the ones used by top-level CAs. > I think the real issue, which you ay have overlooked in my comments above, is the notion that the best candidate for a CA is an entity that is authoritative for the identity asserted in the cert. Based on you reply, I get the sense that you're focusing on CAs like the current set of browser TAs, all of which fail to meet the criteria I cited. Steve From hallam@gmail.com Wed Feb 8 12:50:13 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB81121F8572 for ; Wed, 8 Feb 2012 12:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfAbb82ebwsu for ; Wed, 8 Feb 2012 12:50:12 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2C5511E8097 for ; Wed, 8 Feb 2012 12:50:12 -0800 (PST) Received: by qcsg13 with SMTP id g13so653921qcs.31 for ; Wed, 08 Feb 2012 12:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:references:from:content-transfer-encoding:content-type :in-reply-to:message-id:date:cc:to:mime-version:x-mailer; bh=MdLgvWCmtbDrgxJ79iMiiVFjZLl7srFTzvukVzuoQsk=; b=w1V7eC8S8UIzbCguXNIniCeqFTi5HSQkWSnGiVhoOZ9XhdW3n4mH5qHmtd8iGLVlzw 4DxVe2NFsyWzwwmsNPyhni0NlDJZ8gIHBOW0g6nWZouJbPETk2+4aggIcmzFVycy03dv ikHKG7F4c+p0zAgmOYke8SWdz9z2EQAGZGD5Y= Received: by 10.224.116.6 with SMTP id k6mr29227317qaq.91.1328734212303; Wed, 08 Feb 2012 12:50:12 -0800 (PST) Received: from [10.10.112.132] (mobile-198-228-198-223.mycingular.net. [198.228.198.223]) by mx.google.com with ESMTPS id el3sm938367qab.8.2012.02.08.12.50.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 12:50:11 -0800 (PST) References: <12020712051780_4AE3A@oregon.uoregon.edu> From: Phillip Hallam-Baker Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> Date: Wed, 8 Feb 2012 15:03:31 -0500 To: Stephen Kent Mime-Version: 1.0 (1.0) X-Mailer: iPad Mail (9A405) Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 20:50:14 -0000 But authentication works in that scenario because the protocols can allow ea= ch user to have as many keys as they need. The key is not shared across devi= ces, the protocols allow for multiple cards per end user Sent from my iPad On Feb 8, 2012, at 12:06, Stephen Kent wrote: > At 6:52 PM -0500 2/7/12, Phillip Hallam-Baker wrote: >=20 >> ... >>=20 >> The reason I no longer believe in end-to-end solutions is that the >> endpoint for a public key is always a machine and the desired endpoint >> is a person. >=20 > yes, the machine is the endpoint, but machines are always in the loop for t= he sorts of transactions we're discussing, unless we're very restrictive. Th= e EU-inspired PIN pad + display that shows the user a number representing a v= alue being authorized by a sig is an exception.) >=20 > So, I don't agree that the distinction between the user and a machine oper= ated by a user is really significant, in the end. (Yes, I am ware of the ma= ny security problems that arise because the user doesn't really know what th= e code is doing, but nothing is perfect.) >=20 >> ... >>=20 >> Any scheme that does not take account of the fact that a user must be >> able to access their account from at lest fifteen different devices, >> some of which will be mobile and possibly lost is useless in the real >> world. The military can tollerate such systems because they will order >> people to use them. >=20 > I agree that credential portability is essential. BTW, the US DoD operates= more like a company with an eye on the bottom line than a monolithic securi= ty-focused organization, as you suggest above :-). >=20 >> S/MIME with a private key shared to fifteen devices no longer looks >> very secure to me. >=20 > Crednetial portability does not necessarily imply a private key kept in SW= in every device. >=20 > Steve From kent@bbn.com Wed Feb 8 14:02:47 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0FB21F84C8 for ; Wed, 8 Feb 2012 14:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.358 X-Spam-Level: X-Spam-Status: No, score=-106.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fJ-kouX+asV for ; Wed, 8 Feb 2012 14:02:46 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7384621F84C4 for ; Wed, 8 Feb 2012 14:02:46 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:39706 helo=[192.67.20.202]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvFbB-000LVY-Au; Wed, 08 Feb 2012 17:02:45 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> Date: Wed, 8 Feb 2012 16:52:11 -0500 To: Phillip Hallam-Baker From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 22:02:47 -0000 At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote: >But authentication works in that scenario because the protocols can >allow each user to have as many keys as they need. The key is not >shared across devices, the protocols allow for multiple cards per >end user > Sorry, I don't understand you comment. Steve From stephen.farrell@cs.tcd.ie Wed Feb 8 14:18:41 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3DB21F8599 for ; Wed, 8 Feb 2012 14:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKJ3CckfOK58 for ; Wed, 8 Feb 2012 14:18:40 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A13621F84E7 for ; Wed, 8 Feb 2012 14:18:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1D3C4171C96; Wed, 8 Feb 2012 22:18:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1328739516; bh=1jOqBLnP0Wo1mz I9io13uttQSLz/5xG0Q3m0U45J2Aw=; b=ftBTkHiHLP1DAFlQOW9SZFaa41F0JY 3FMpS+LhyW6DZc0WO91+P8ki2e81Cu3VnSVn9p8FqL/f77BzBOsgI8fYIN6jXoiX VCG1XyO3I0vcTqYeOz7tRUx5h+9cQfxrLAM6Msyt3hPLH1GvHHo/05hfIBngiNew jw9ZG7VYX0YEna07jR7ZQ/BSNRvQ8uE8QiNOikzGwWx672IraFRuAn5LL94dsq2P 5MPNDawzi/Z2r6yckCSTi1H11Omg6DXeg9e8tehBpMZHIP6bSLwzDB6t4kVj3/1w zQhNwnirVahc4Y43+UnXtscmt3ZVm7jvP60vSkcyNEpRSynkfS4HXp3A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id HkEtHoffRBlq; Wed, 8 Feb 2012 22:18:36 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.42.24.40]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 63F02171C95; Wed, 8 Feb 2012 22:18:35 +0000 (GMT) Message-ID: <4F32F4BA.1000307@cs.tcd.ie> Date: Wed, 08 Feb 2012 22:18:34 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Ben Laurie References: <008d01cce5f1$2b322f50$81968df0$@globalsign.com> <07b401cce685$a38fc950$eaaf5bf0$@globalsign.com> <087101cce692$75ca07d0$615e1770$@globalsign.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Joe St Sauver , Ryan Hurst , therightkey@ietf.org, Stephen Kent Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 22:18:41 -0000 On 02/08/2012 07:19 PM, Ben Laurie wrote: > On 8 February 2012 18:49, Ryan Hurst wrote: > >> One of the things I like about BrowserID as an approach is that I agree >> with others that the portability of key material in today’s world is >> important and by them including the vetting of the ownership of an email in >> their key provisioning workflow they kind of address this problem. >> On the OBC theme, I do like that. (Though I think signalling it via an HTTP authentication scheme would be an improvement as well but that's a detail.) One thing that could be done with OBC would be to not try to move the private keys, but rather provide a standard way to bind different OBC public keys on the user's different devices to the same server account. So, e.g. to associate two devices to the same account the user would be sent to https://example.com/.well-known/obc-bind and after TLS mutual auth would be shown e.g. a short-lived code that could then be entered on a form at the same URL accessed from another device. The UI for that needn't be standard so servers could innovate fairly freely there I think. If the user can bind various devices to the same server account then I think a bunch of account registration and recovery options become available without having to ever move a private key and also without having to bake the registration part into the TLS authentication scheme. It still doesn't do logout though, but personally I don't really get why that's such a deal. I suspect that if we did have logout then malware would just adapt and overall we'd not be that much better off. Maybe I don't get the real requirement there though. > Then you might like the work I did on portability of key material: > http://www.links.org/files/nigori-overview.pdf. I don't get how this differs at all from any centralised login service nor, if its just a key store, why it'd prove any more popular than sacred was, though maybe that's long enough ago that things have changed enough (the EKE patent expired in the meantime at least;-) S. From frantz@pwpconsult.com Wed Feb 8 14:40:15 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F404F11E8099 for ; Wed, 8 Feb 2012 14:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXsF7H7wO2-4 for ; Wed, 8 Feb 2012 14:40:14 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 40CDD11E808C for ; Wed, 8 Feb 2012 14:40:14 -0800 (PST) Received: from [173.75.83.131] (helo=Bill-Frantzs-MacBook-Pro.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RvGBR-0002K8-Dm; Wed, 08 Feb 2012 17:40:13 -0500 Date: Wed, 8 Feb 2012 14:40:13 -0800 From: Bill Frantz To: Stephen Kent X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79379b73e68aeb6b80d8900cd4da6ddaa3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.131 Cc: therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 22:40:15 -0000 On 2/7/12 at 11:55, kent@bbn.com (Stephen Kent) wrote: >Keys are not really great identifiers; they change, Keys don't change. People or programs may wish to change the=20 keys they are using, but keys themselves are constant. >they are not human meaningful (and thus there has to be another=20 >layer of mapping between key and human-readable IDs, which=20 >creates more vulnerabilities), etc. It the key represents an authorization, it may not need to be=20 human meaningful. We get a lot of comments wanting to achieve some level of=20 assurance about identification. For most uses, we are more=20 interested in authorization than in identification. (If we need=20 identification for auditing purposes, it can be included in the=20 the authorization. For example: Authorization to deposit to account 123456 as Joe User. There are any number of approaches to providing secure=20 authorizations, some of which can be bookmarked in standard browsers. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Airline peanut bag: "Produced | Periwinkle (408)356-8506 | in a facility that processes | 16345=20 Englewood Ave www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos,=20 CA 95032 From hallam@gmail.com Wed Feb 8 17:22:23 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55ACD21F847B for ; Wed, 8 Feb 2012 17:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 627bRZBMzkiS for ; Wed, 8 Feb 2012 17:22:22 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B02421F84F1 for ; Wed, 8 Feb 2012 17:22:20 -0800 (PST) Received: by obbwd15 with SMTP id wd15so1876035obb.31 for ; Wed, 08 Feb 2012 17:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QTe6nWGYAK58uWeHRn1hxS/XRSf9sc5hRpyu+METcz8=; b=MEVQ3wr9zEURtgPAUy7OzibXTkErGaX4UifzPccLnANSBGQaejmQzlM9pE1G5mfTLu T+MC1Mq1+q+Nru+tZHJhM9rTPWm3a+o6qcpzhdZJ7PrtlXfEPQqAkGhyFtovwWv8u5SH zCtwfIF423zCDT6paXnJSLsIYwAMCn864tDfU= MIME-Version: 1.0 Received: by 10.182.1.104 with SMTP id 8mr6222445obl.19.1328750539963; Wed, 08 Feb 2012 17:22:19 -0800 (PST) Received: by 10.182.75.138 with HTTP; Wed, 8 Feb 2012 17:22:19 -0800 (PST) In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> Date: Wed, 8 Feb 2012 20:22:19 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 01:22:23 -0000 Alice has three mobile phones and six laptops. Using embedded keys in those devices for authorization is no problem since each device can have a separate private key and the authentication server tracks the fact that there are nine devices that might authenticate Alice. The same model can even be made to work for confidentiality. Alice can read her DRM protected Kindle content on any one of those devices. (Though there may be limits on how many devices the DRM scheme will permit). Trying to make S/MIME email work in that scenario is futile. The sender only tracks one private key for Alice. So Alice has to export her private key to all her S/MIME clients. Not only is that terrible security practice, it is too much work. Worse, Alice has to repeat the process once a year. That is why I no longer believe that end-to-end is a desirable quality. A security requirement that does not consider the cost it imposes versus the risks it mitigates is ideology. On Wed, Feb 8, 2012 at 4:52 PM, Stephen Kent wrote: > At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote: >> >> But authentication works in that scenario because the protocols can allow >> each user to have as many keys as they need. The key is not shared across >> devices, the protocols allow for multiple cards per end user >> > Sorry, I don't understand you comment. > > Steve -- Website: http://hallambaker.com/ From zack.weinberg@gmail.com Wed Feb 8 17:46:33 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B68611E808F for ; Wed, 8 Feb 2012 17:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFut52AzqDcZ for ; Wed, 8 Feb 2012 17:46:32 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 931BE11E8072 for ; Wed, 8 Feb 2012 17:46:32 -0800 (PST) Received: by obbwd15 with SMTP id wd15so1904584obb.31 for ; Wed, 08 Feb 2012 17:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bomzlhyDXOPWSpXDwc2QtyoJJoMgBN6igEfiZVhoFXY=; b=DuZtYfC0QinSU+WSrLlFo9RAxVnLI98/vZwb73zlLGxe9N6giCee4FwPAuS8JgRy1K ux5cZedoO9P9Xq/04mzYtspl0ayXwxTSNaVZzExY01erTqMY0STi6LRDi9ZBtfxLW7PA kp2EQ7AnNQWXjnFuf5g20ha5DWkmoMZ2mi23w= MIME-Version: 1.0 Received: by 10.182.109.106 with SMTP id hr10mr28339434obb.27.1328751992275; Wed, 08 Feb 2012 17:46:32 -0800 (PST) Sender: zack.weinberg@gmail.com Received: by 10.182.78.101 with HTTP; Wed, 8 Feb 2012 17:46:32 -0800 (PST) In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> Date: Wed, 8 Feb 2012 17:46:32 -0800 X-Google-Sender-Auth: WnLZMZ5N1rHbkrdPxtCtaCXN0iM Message-ID: From: Zack Weinberg To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: "therightkey@ietf.org" , Stephen Kent Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 01:46:33 -0000 On Wed, Feb 8, 2012 at 5:22 PM, Phillip Hallam-Baker wrote: > Alice has three mobile phones and six laptops. ... > Trying to make S/MIME email work in that scenario is futile. The > sender only tracks one private key for Alice. So Alice has to export > her private key to all her S/MIME clients. Not only is that terrible > security practice, it is too much work. Worse, Alice has to repeat the > process once a year. This is a special case of the confidentiality scenario, isn't it? Alice's private key is stored somewhere in the cloud, and the server will send it only to a device that can authenticate as Alice's device. But you also want to prevent the server from impersonating Alice: so the key needs to be encrypted on the server, and decrypted on the device. The dumb, probably good-enough way to do that is to have Alice enter a passphrase on the device which gets PBKDFed to the decryption key. I bet there's something cleverer in the land of secret sharing schemes, but I'd have to go dig it up. zw From stephen.farrell@cs.tcd.ie Wed Feb 8 18:11:16 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBD421F85D6 for ; Wed, 8 Feb 2012 18:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.238 X-Spam-Level: X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTpFjlE83y47 for ; Wed, 8 Feb 2012 18:11:15 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id D52C221F85CF for ; Wed, 8 Feb 2012 18:11:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6D29E171C96 for ; Thu, 9 Feb 2012 02:11:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1328753466; bh=H5KoOoCRnh3GHk qUl5IC+ct+m34uMOAfxw+OBElx0hw=; b=puy3wPQpuzXM7HSFzviBgFMQ9lGrcw u18Zt3/gE8vYISH/84RYqN7xoINBnBbsofoUUkakt1FRV32YqkkbYY5dlxhkvpqD Fa0IrMcghO95HEkvnXgvWGjeoE++gVt5bhv6MZQuv2Jpx8iWyCRBJKhMVSCc9n6G tvFhdjjUtK/aWF2ZdyVUZtXtYs1pBRjR0DIlYpDx+bGLzfpPlGPfnt0aQJKfcUJG RQ64YmQV7adidZhJqyzjsPVk9+vOhFgb/KnRHhDpNuzdSSFehePn4hFxS9Pzt0Ia q/514GtSCTff6Ohj8ee/YaCpGNnxhDtS9Rq7VXnu0B6OYvwQ2lpsxZQA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id TR8S9g9MDCpV for ; Thu, 9 Feb 2012 02:11:06 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.42.24.40]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 07D2A171C95 for ; Thu, 9 Feb 2012 02:11:06 +0000 (GMT) Message-ID: <4F332B39.7090805@cs.tcd.ie> Date: Thu, 09 Feb 2012 02:11:05 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [therightkey] focus (Was: Re: Will the real RPF please stand up?) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 02:11:16 -0000 So S/MIME works fine in many cases but does not work well between random people connected to the Internet, unlike email. That's a pity. Its not an easy problem though, XMPP have been trying for a good while and we don't even seem to have a good solution for SIP or Diameter which ought be much easier. I guess if this discussion lead to a way to manage keys that could work at the same scale as email that would be a major advance. I don't expect that myself. And of course, whatever the right answer there (if there is one) is maybe very different from how we might manage keys for web servers or MTAs or XMPP servers. Maybe we ought also think about whether or not the same key management scheme is right for all those or not as part of this too and whether we're able to solve all or just some/one of those problems. Put another way: maybe it'd be better to tighten the focus a teeny bit more on this list. Specific suggestions for topics welcome. Why not start a new thread with your favourite problem that's worth solving and maybe solveable. (Being the IETF, we're not very interested in other things in the end:-) S. PS: I bet I'm not the only one who can no longer associate the subject line with the content. Be good to be better at that since it'll help to try move towards some concrete outcomes here. On 02/09/2012 01:22 AM, Phillip Hallam-Baker wrote: > Alice has three mobile phones and six laptops. > > Using embedded keys in those devices for authorization is no problem > since each device can have a separate private key and the > authentication server tracks the fact that there are nine devices that > might authenticate Alice. > > The same model can even be made to work for confidentiality. Alice can > read her DRM protected Kindle content on any one of those devices. > (Though there may be limits on how many devices the DRM scheme will > permit). > > > Trying to make S/MIME email work in that scenario is futile. The > sender only tracks one private key for Alice. So Alice has to export > her private key to all her S/MIME clients. Not only is that terrible > security practice, it is too much work. Worse, Alice has to repeat the > process once a year. > > That is why I no longer believe that end-to-end is a desirable > quality. A security requirement that does not consider the cost it > imposes versus the risks it mitigates is ideology. > > > On Wed, Feb 8, 2012 at 4:52 PM, Stephen Kent wrote: >> At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote: >>> >>> But authentication works in that scenario because the protocols can allow >>> each user to have as many keys as they need. The key is not shared across >>> devices, the protocols allow for multiple cards per end user >>> >> Sorry, I don't understand you comment. >> >> Steve > > > From aerowolf@gmail.com Wed Feb 8 19:09:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29D611E80A3 for ; Wed, 8 Feb 2012 19:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2OnSZymR6wC for ; Wed, 8 Feb 2012 19:09:06 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6FF821F84F3 for ; Wed, 8 Feb 2012 19:09:05 -0800 (PST) Received: by iagf6 with SMTP id f6so2121522iag.31 for ; Wed, 08 Feb 2012 19:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=ccihAc29oevstI3zcdh/Y/1SkDZErp9jC6sZ1qJJ8Ak=; b=bdI0oo+kRVD1MS5enxBKX6l/zfl+2m+S0fzv8g/gUZBxdXpgL4M7HX7z1KwsGET06c 2nh0PiFaoVkQ+uO8dx5mx0OB7aqqz3IsGVXLY6TqGe3L/mpjWLVPybsCxhlpzwWgMyMW 6KjAnLCsChs/4e0UpfLVARDOz+X9V7XYe2+bs= Received: by 10.42.171.136 with SMTP id j8mr35567icz.1.1328756945481; Wed, 08 Feb 2012 19:09:05 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id k3sm3087707igq.1.2012.02.08.19.09.03 (version=SSLv3 cipher=OTHER); Wed, 08 Feb 2012 19:09:04 -0800 (PST) From: "Kyle Hamilton" To: "Stephen Farrell" Date: Wed, 8 Feb 2012 19:09:03 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: <4F332B39.7090805@cs.tcd.ie> References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgyf7kr3p8n9xnzcldy2 Cc: "therightkey@ietf.org" Subject: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 03:09:07 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgyf7kr3p8n9xnzcldy2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 T25jZSB1cG9uIGEgdGltZSBpbiB0aGUgSUVURiwgdGhlcmUgd2FzIGEgbWFuZGF0b3J5LXRvLWlt cGxlbWVudCBjaXBoZXIuICBUaGlzIGNpcGhlciB3YXMgdGhlIGJlc3Qtc2VsZWN0ZWQgYXQgdGhl IHRpbWUsIHVzaW5nIGN1dHRpbmctZWRnZSB0ZWNobm9sb2dpZXMuDQoNClRpbWUgY2hhbmdlZC4g IFRoZSBuZXcgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBjaXBoZXIgY2FtZSBhbG9uZy4NCg0KV2h5 IGhhdmVuJ3Qgd2UgZXZlciBjb25zaWRlcmVkIHRoYXQgbWF5YmUgUy9NSU1FIGRvZXNuJ3QgaGF2 ZSB0byBiZSBmdWxseSBhdXRoZW50aWNhdGVkIG9uIGZpcnN0IGNvbnRhY3Q/ICBXaHkgaGF2ZW4n dCB3ZSBjb25zaWRlcmVkIHRoYXQgd2l0aCBvbmx5IGEgc2luZ2xlIGNlcnRpZmljYXRlIGNoYWlu LCB0aGUgdXNlciB3b3VsZCBmaXJzdCBoYXZlIHRvIGNvbW11bmljYXRlIGhpcyBNVUEgY2FwYWJp bGl0aWVzIHRvIGhpcyBDQSBhbmQgdGhlbiBub3QgdXBncmFkZSBoaXMgbWFpbCBjbGllbnQgd2l0 aG91dCBjb29yZGluYXRpb24/DQoNCkluc3RlYWQsIHdlIHNob3VsZCBoYXZlIGEgbmV3IGhlYWRl ciBpbiBvdXIgZW1haWwuICBYLVNlY3VyZS1NSU1FLUNhcGFiaWxpdGllczoNCg0KV2UgY291bGQg bWFrZSBpdCBjb250YWluIGEgYmFzZTY0LWVuY29kZWQgcmVwcmVzZW50YXRpb24gb2Ygd2hhdCB0 aGUgQ2FwYWJpbGl0aWVzIGV4dGVuc2lvbidzIE9DVEVUIFNUUklORyB3b3VsZCBjb250YWluLiAg T3Igd2UgY291bGQgYXNzaWduIGxhYmVscyB0byB0aGUgdmFyaW91cyBjaXBoZXIgYWxnb3JpdGht cyB0byBtYWtlIHRoZW0gaHVtYW4tcmVhZGFibGUuDQoNCkluc3RlYWQgb2YgdGhpbmtpbmcgYWxv bmcgdGhlIGxpbmVzIG9mICJvbmx5IHRoZSBuYW1lZCByZWNpcGllbnQgd2lsbCBnZXQgaXQiLCB3 aHkgZG9uJ3Qgd2Ugc3RhcnQgdGhpbmtpbmcgYWxvbmcgdGhlIGxpbmVzIG9mICJ0aGUgZGVzdGlu YXRpb24gbWFpbGJveCB3aWxsIGJlIGFibGUgdG8gZ2V0IGl0Ij8NCg0KRnJvbSB0aGVyZSwgaXQg YmVjb21lcyBmYWlybHkgZWFzeS4gICJJIG11c3QgZW5zdXJlIHRoYXQgdGhlIHN5bW1ldHJpYyBr ZXkgdXNlZCB0byBlbmNyeXB0IHRoZSBtZXNzYWdlIGNhbiBiZSBkZWNyeXB0ZWQgYnkgYWxsIG9m IG15IHVzZXIgZGV2aWNlcyBhbmQgcmVjb3Zlcnkga2V5cy4iICBBIHByb2NtYWlsIHJlY2lwZSBj b3VsZCBwZXJoYXBzIHJlLXNlbmQgdGhlIG1lc3NhZ2Ugd2l0aCBhZGRpdGlvbmFsIHJlY2lwaWVu dCBrZXlzLg0KDQpBdCB0aGF0IHBvaW50LCBpdCdzICJ3aGF0IGlmIEkgZG9uJ3QgaGF2ZSBteSBr ZXlzIG9uIHRoZSBkZXZpY2Ugd2hlcmUgSSBjYW4gcnVuIHByb2NtYWlsPyIgIElNQVAgYmVjb21l cyBhIHVzZWZ1bCB0b29sLCBhcyBkb2VzIFBPUDMuICBUaGV5IGNhbid0IGFsdGVyIG1lc3NhZ2Vz LCBidXQgdGhleSBwZXJtaXQgYSBkYWVtb24gdGhhdCBjYW4sIGZvciBleGFtcGxlLCBlbnN1cmUg dGhhdCBpdHMgcmUobXVsdGlwbHkpZGVzdGluZWQgbWVzc2FnZXMgbWFrZSBpdCBiYWNrIGludG8g dGhlIG1haWxib3ggYmVmb3JlIHRoZSBvcmlnaW5hbCwgc2luZ2xlLWRlc3RpbmF0aW9uIG1lc3Nh Z2UgaXMgcHVyZ2VkLg0KDQpUaGlzIHdvdWxkIGFsc28gYWxsb3cgZm9yIGFkZGl0aW9uYWwgY29t bWFuZHMgdG8gYmUgc2VudCBmcm9tIHRoZSBkZXZpY2VzIHRvIHRoZSBrZXlzdG9yZSwgc3VjaCBh cyAic2lnbiB0aGlzIHdpdGggbXkgY29ycG9yYXRlIGtleSIgb3IgInNlbmQgdGhpcyB0byBhZXJv d29sZkBnbWFpbC5jb20gd2l0aCB0aGUgYmVzdCBzZWN1cml0eSB5b3Uga25vdyBob3cgdG8gZG8i Lg0KDQpUaGUgcHJvYmxlbSBpcy4uLj8NCg0KLUt5bGUgSA0KDQpPbiBXZWQsIEZlYiA4LCAyMDEy IGF0IDY6MTEgUE0sIFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4g d3JvdGU6DQo+DQo+IDx0cnlpbmcgdG8gcG9rZSB0aGluZ3MgYWxvbmcgYSBiaXQgbW9yZSBhY3Rp dmVseSBoYXQgb24+DQo+DQo+IFNvIFMvTUlNRSB3b3JrcyBmaW5lIGluIG1hbnkgY2FzZXMgYnV0 IGRvZXMgbm90IHdvcmsgd2VsbA0KPiBiZXR3ZWVuIHJhbmRvbSBwZW9wbGUgY29ubmVjdGVkIHRv IHRoZSBJbnRlcm5ldCwgdW5saWtlIGVtYWlsLg0KPiBUaGF0J3MgYSBwaXR5Lg0KPg0KPiBJdHMg bm90IGFuIGVhc3kgcHJvYmxlbSB0aG91Z2gsIFhNUFAgaGF2ZSBiZWVuIHRyeWluZyBmb3IgYQ0K PiBnb29kIHdoaWxlIGFuZCB3ZSBkb24ndCBldmVuIHNlZW0gdG8gaGF2ZSBhIGdvb2Qgc29sdXRp b24gZm9yDQo+IFNJUCBvciBEaWFtZXRlciB3aGljaCBvdWdodCBiZSBtdWNoIGVhc2llci4NCj4N Cj4gSSBndWVzcyBpZiB0aGlzIGRpc2N1c3Npb24gbGVhZCB0byBhIHdheSB0byBtYW5hZ2Uga2V5 cyB0aGF0DQo+IGNvdWxkIHdvcmsgYXQgdGhlIHNhbWUgc2NhbGUgYXMgZW1haWwgdGhhdCB3b3Vs ZCBiZSBhIG1ham9yDQo+IGFkdmFuY2UuIEkgZG9uJ3QgZXhwZWN0IHRoYXQgbXlzZWxmLg0KPg0K PiBBbmQgb2YgY291cnNlLCB3aGF0ZXZlciB0aGUgcmlnaHQgYW5zd2VyIHRoZXJlIChpZiB0aGVy ZQ0KPiBpcyBvbmUpIGlzIG1heWJlIHZlcnkgZGlmZmVyZW50IGZyb20gaG93IHdlIG1pZ2h0IG1h bmFnZSBrZXlzDQo+IGZvciB3ZWIgc2VydmVycyBvciBNVEFzIG9yIFhNUFAgc2VydmVycy4NCj4N Cj4gTWF5YmUgd2Ugb3VnaHQgYWxzbyB0aGluayBhYm91dCB3aGV0aGVyIG9yIG5vdCB0aGUgc2Ft ZSBrZXkNCj4gbWFuYWdlbWVudCBzY2hlbWUgaXMgcmlnaHQgZm9yIGFsbCB0aG9zZSBvciBub3Qg YXMgcGFydCBvZg0KPiB0aGlzIHRvbyBhbmQgd2hldGhlciB3ZSdyZSBhYmxlIHRvIHNvbHZlIGFs bCBvciBqdXN0IHNvbWUvb25lDQo+IG9mIHRob3NlIHByb2JsZW1zLg0KPg0KPiBQdXQgYW5vdGhl ciB3YXk6IG1heWJlIGl0J2QgYmUgYmV0dGVyIHRvIHRpZ2h0ZW4gdGhlIGZvY3VzDQo+IGEgdGVl bnkgYml0IG1vcmUgb24gdGhpcyBsaXN0LiBTcGVjaWZpYyBzdWdnZXN0aW9ucyBmb3IgdG9waWNz DQo+IHdlbGNvbWUuIFdoeSBub3Qgc3RhcnQgYSBuZXcgdGhyZWFkIHdpdGggeW91ciBmYXZvdXJp dGUNCj4gcHJvYmxlbSB0aGF0J3Mgd29ydGggc29sdmluZyBhbmQgbWF5YmUgc29sdmVhYmxlLiAo QmVpbmcgdGhlDQo+IElFVEYsIHdlJ3JlIG5vdCB2ZXJ5IGludGVyZXN0ZWQgaW4gb3RoZXIgdGhp bmdzIGluIHRoZSBlbmQ6LSkNCj4NCj4gUy4NCj4NCj4gUFM6IEkgYmV0IEknbSBub3QgdGhlIG9u bHkgb25lIHdobyBjYW4gbm8gbG9uZ2VyIGFzc29jaWF0ZQ0KPiB0aGUgc3ViamVjdCBsaW5lIHdp dGggdGhlIGNvbnRlbnQuIEJlIGdvb2QgdG8gYmUgYmV0dGVyIGF0DQo+IHRoYXQgc2luY2UgaXQn bGwgaGVscCB0byB0cnkgbW92ZSB0b3dhcmRzIHNvbWUgY29uY3JldGUNCj4gb3V0Y29tZXMgaGVy ZS4NCj4NCj4gT24gMDIvMDkvMjAxMiAwMToyMiBBTSwgUGhpbGxpcCBIYWxsYW0tQmFrZXIgd3Jv dGU6DQo+Pg0KPj4gQWxpY2UgaGFzIHRocmVlIG1vYmlsZSBwaG9uZXMgYW5kIHNpeCBsYXB0b3Bz Lg0KPj4NCj4+IFVzaW5nIGVtYmVkZGVkIGtleXMgaW4gdGhvc2UgZGV2aWNlcyBmb3IgYXV0aG9y aXphdGlvbiBpcyBubyBwcm9ibGVtDQo+PiBzaW5jZSBlYWNoIGRldmljZSBjYW4gaGF2ZSBhIHNl cGFyYXRlIHByaXZhdGUga2V5IGFuZCB0aGUNCj4+IGF1dGhlbnRpY2F0aW9uIHNlcnZlciB0cmFj a3MgdGhlIGZhY3QgdGhhdCB0aGVyZSBhcmUgbmluZSBkZXZpY2VzIHRoYXQNCj4+IG1pZ2h0IGF1 dGhlbnRpY2F0ZSBBbGljZS4NCj4+DQo+PiBUaGUgc2FtZSBtb2RlbCBjYW4gZXZlbiBiZSBtYWRl IHRvIHdvcmsgZm9yIGNvbmZpZGVudGlhbGl0eS4gQWxpY2UgY2FuDQo+PiByZWFkIGhlciBEUk0g cHJvdGVjdGVkIEtpbmRsZSBjb250ZW50IG9uIGFueSBvbmUgb2YgdGhvc2UgZGV2aWNlcy4NCj4+ IChUaG91Z2ggdGhlcmUgbWF5IGJlIGxpbWl0cyBvbiBob3cgbWFueSBkZXZpY2VzIHRoZSBEUk0g c2NoZW1lIHdpbGwNCj4+IHBlcm1pdCkuDQo+Pg0KPj4NCj4+IFRyeWluZyB0byBtYWtlIFMvTUlN RSBlbWFpbCB3b3JrIGluIHRoYXQgc2NlbmFyaW8gaXMgZnV0aWxlLiBUaGUNCj4+IHNlbmRlciBv bmx5IHRyYWNrcyBvbmUgcHJpdmF0ZSBrZXkgZm9yIEFsaWNlLiBTbyBBbGljZSBoYXMgdG8gZXhw b3J0DQo+PiBoZXIgcHJpdmF0ZSBrZXkgdG8gYWxsIGhlciBTL01JTUUgY2xpZW50cy4gTm90IG9u bHkgaXMgdGhhdCB0ZXJyaWJsZQ0KPj4gc2VjdXJpdHkgcHJhY3RpY2UsIGl0IGlzIHRvbyBtdWNo IHdvcmsuIFdvcnNlLCBBbGljZSBoYXMgdG8gcmVwZWF0IHRoZQ0KPj4gcHJvY2VzcyBvbmNlIGEg eWVhci4NCj4+DQo+PiBUaGF0IGlzIHdoeSBJIG5vIGxvbmdlciBiZWxpZXZlIHRoYXQgZW5kLXRv LWVuZCBpcyBhIGRlc2lyYWJsZQ0KPj4gcXVhbGl0eS4gQSBzZWN1cml0eSByZXF1aXJlbWVudCB0 aGF0IGRvZXMgbm90IGNvbnNpZGVyIHRoZSBjb3N0IGl0DQo+PiBpbXBvc2VzIHZlcnN1cyB0aGUg cmlza3MgaXQgbWl0aWdhdGVzIGlzIGlkZW9sb2d5Lg0KPj4NCj4+DQo+PiBPbiBXZWQsIEZlYiA4 LCAyMDEyIGF0IDQ6NTIgUE0sIFN0ZXBoZW4gS2VudDxrZW50QGJibi5jb20+IKB3cm90ZToNCj4+ Pg0KPj4+IEF0IDM6MDMgUE0gLTA1MDAgMi84LzEyLCBQaGlsbGlwIEhhbGxhbS1CYWtlciB3cm90 ZToNCj4+Pj4NCj4+Pj4NCj4+Pj4gQnV0IGF1dGhlbnRpY2F0aW9uIHdvcmtzIGluIHRoYXQgc2Nl bmFyaW8gYmVjYXVzZSB0aGUgcHJvdG9jb2xzIGNhbg0KPj4+PiBhbGxvdw0KPj4+PiBlYWNoIHVz ZXIgdG8gaGF2ZSBhcyBtYW55IGtleXMgYXMgdGhleSBuZWVkLiBUaGUga2V5IGlzIG5vdCBzaGFy ZWQNCj4+Pj4gYWNyb3NzDQo+Pj4+IGRldmljZXMsIHRoZSBwcm90b2NvbHMgYWxsb3cgZm9yIG11 bHRpcGxlIGNhcmRzIHBlciBlbmQgdXNlcg0KPj4+Pg0KPj4+IFNvcnJ5LCBJIGRvbid0IHVuZGVy c3RhbmQgeW91IGNvbW1lbnQuDQo+Pj4NCj4+PiBTdGV2ZQ0KPj4NCj4+DQo+Pg0KPj4NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdGhlcmlnaHRr ZXkgbWFpbGluZyBsaXN0DQo+IHRoZXJpZ2h0a2V5QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdGhlcmlnaHRrZXkNCg0K --gmsm1.9.5eqgyf7kr3p8n9xnzcldy2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMDkwMzA5MDNaMCMGCSqGSIb3DQEJBDEWBBRPuuEs3j9c+41EQG8AlNWF 9zcUMjBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAlYvmv0YnofaNoO6hNgySYjvTiFOVkyahUuf+41ZbWzii4bse9EpkwdhHq79p3MFG2Mhe vNjAFPMEUYxwPxEAMkcMkZodXN8D9XtEby3i4wGKF7xmWO5X1G4KewoFVJH3145pazA0jFuByX+s jspplRiwdsnDohJSgWaNxB6BIqcBKeg6R8jJiyD/znTcvNUonokbk010I3Vn8pcWuZytq1/ILYUw Q/fBuiAbe8uef8HHoS7Bg9sAJzPCUiYu4hpM1vuiMb4AMVZ+ZZM+uTOJk2WI4ASM5UptPUTKMRxE 1Q5x4AUmT+JlRxL76P9rDCqYBLIDboEoxaSw6i1WdaD9lQAAAAAAAA== --gmsm1.9.5eqgyf7kr3p8n9xnzcldy2-- From hallam@gmail.com Wed Feb 8 19:15:50 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9D611E80A1 for ; Wed, 8 Feb 2012 19:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.356 X-Spam-Level: X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTbFprsxn88W for ; Wed, 8 Feb 2012 19:15:50 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBB911E8098 for ; Wed, 8 Feb 2012 19:15:50 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2011429obb.31 for ; Wed, 08 Feb 2012 19:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=D7PySS3WF5s2w8A0xIWOfQV3mY4+/iZGxktQP6tQtwk=; b=c05EKYBiJ6PKJXrBqtnUNSFJ8bA4WCp0ipXvI+C3CDzBIGwyXZRu/lLUqmaa3AtGjc H3Q73iqeK3uLOpFKlm3itAMHrrSQtmZmmrLcgjtN/k1CD0HF8ell+P/TzpyRU+yVwKfw FC4nGt9RvX6p/vrvnnvoubwsL8m5WjGKboD7U= MIME-Version: 1.0 Received: by 10.182.1.104 with SMTP id 8mr14194obl.19.1328757349989; Wed, 08 Feb 2012 19:15:49 -0800 (PST) Received: by 10.182.75.138 with HTTP; Wed, 8 Feb 2012 19:15:49 -0800 (PST) In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> Date: Wed, 8 Feb 2012 22:15:49 -0500 Message-ID: From: Phillip Hallam-Baker To: Zack Weinberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" , Stephen Kent Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 03:15:51 -0000 Umm, no, I was showing why end-to-end works for authentication (no need for the same key in every device) but not for S/MIME. The way to make S/MIME practical for Alice would be to do as you suggest and have Alice's private key out there in the cloud somewhere and have the server where it is kept be in charge of decrypting inbound messages and then re-encrypting them for each of Alice's devices. This is a very good model for protecting content, but it is not end to end, there is a bump in the wire where the email messages are being decrypted and re-encrypted. So in practice this use of S/MIME is no more end-to-end than SMTP over SSL. Now I guess we could throw some crypto pixie dust over the scheme maybe and reduce the ability of the intermediary to default, but in the real world nobody is now going to accept encrypted email from just anyone. Well not once the number of other people doing that has risen to the point where it is worthwhile spamming PGP or S/MIME users. On Wed, Feb 8, 2012 at 8:46 PM, Zack Weinberg wr= ote: > On Wed, Feb 8, 2012 at 5:22 PM, Phillip Hallam-Baker w= rote: >> Alice has three mobile phones and six laptops. > ... >> Trying to make S/MIME email work in that scenario is futile. The >> sender only tracks one private key for Alice. So Alice has to export >> her private key to all her S/MIME clients. Not only is that terrible >> security practice, it is too much work. Worse, Alice has to repeat the >> process once a year. > > This is a special case of the confidentiality scenario, isn't it? > Alice's private key is stored somewhere in the cloud, and the server > will send it only to a device that can authenticate as Alice's device. > =A0But you also want to prevent the server from impersonating Alice: so > the key needs to be encrypted on the server, and decrypted on the > device. The dumb, probably good-enough way to do that is to have Alice > enter a passphrase on the device which gets PBKDFed to the decryption > key. =A0I bet there's something cleverer in the land of secret sharing > schemes, but I'd have to go dig it up. > > zw --=20 Website: http://hallambaker.com/ From hallam@gmail.com Wed Feb 8 19:40:59 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A75D11E8098 for ; Wed, 8 Feb 2012 19:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.362 X-Spam-Level: X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFAGQBbtfkvO for ; Wed, 8 Feb 2012 19:40:58 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0BD221F84A0 for ; Wed, 8 Feb 2012 19:40:58 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2043252obb.31 for ; Wed, 08 Feb 2012 19:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=A6JQhyKIlkZ+x1BPOviOMoPhEAbI8XAjh9sxGdNyw+0=; b=nnMAy9fXniksKj5m0y4HWcMH1dIL1onZxPYuukypFk14ZNc0DSBf0OMJg9y/4pI9tH 1E8mMJJALePOUO7F6Ie1nH51XAg0ZlgCjwIF0ZwN9a66zbEJ6MSzjtHLuPF5E/Y5LPfI AMIiO4iWAfH8hXky/+ZsLfyapDS8K3ctnMSgs= MIME-Version: 1.0 Received: by 10.182.160.37 with SMTP id xh5mr65324obb.29.1328758858372; Wed, 08 Feb 2012 19:40:58 -0800 (PST) Received: by 10.182.75.138 with HTTP; Wed, 8 Feb 2012 19:40:58 -0800 (PST) In-Reply-To: <4F332B39.7090805@cs.tcd.ie> References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> Date: Wed, 8 Feb 2012 22:40:58 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" Subject: Re: [therightkey] focus (Was: Re: Will the real RPF please stand up?) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 03:40:59 -0000 I think we have a set of requirements that point to a need for three separable technologies: 1) A means by which a site can express the intended security policy 2) An append only notary service 3) A means by which a client can obtain security policy curated by a fourth party Each of these components can be designed in stovepipe fashion to only serve one set of requirements or they can be conceived in slightly more general form. For example, Convergence, SK and CT all involve some form of append only notary. Such a facility would have far more general applicability than just addressing public keys. It might well be easier to get a broad range of parties establishing and supporting the necessary ecology of notary service providers if they are designed in such a fashion that they can be used for general purposes. So I will make separate protocol proposals in each area, but I think what we are designing is going to be easier to deploy if we give some thought to re-usability of components and dual use. On Wed, Feb 8, 2012 at 9:11 PM, Stephen Farrell wrote: > > > > So S/MIME works fine in many cases but does not work well > between random people connected to the Internet, unlike email. > That's a pity. > > Its not an easy problem though, XMPP have been trying for a > good while and we don't even seem to have a good solution for > SIP or Diameter which ought be much easier. > > I guess if this discussion lead to a way to manage keys that > could work at the same scale as email that would be a major > advance. I don't expect that myself. > > And of course, whatever the right answer there (if there > is one) is maybe very different from how we might manage keys > for web servers or MTAs or XMPP servers. > > Maybe we ought also think about whether or not the same key > management scheme is right for all those or not as part of > this too and whether we're able to solve all or just some/one > of those problems. > > Put another way: maybe it'd be better to tighten the focus > a teeny bit more on this list. Specific suggestions for topics > welcome. Why not start a new thread with your favourite > problem that's worth solving and maybe solveable. (Being the > IETF, we're not very interested in other things in the end:-) > > S. > > PS: I bet I'm not the only one who can no longer associate > the subject line with the content. Be good to be better at > that since it'll help to try move towards some concrete > outcomes here. > > On 02/09/2012 01:22 AM, Phillip Hallam-Baker wrote: >> >> Alice has three mobile phones and six laptops. >> >> Using embedded keys in those devices for authorization is no problem >> since each device can have a separate private key and the >> authentication server tracks the fact that there are nine devices that >> might authenticate Alice. >> >> The same model can even be made to work for confidentiality. Alice can >> read her DRM protected Kindle content on any one of those devices. >> (Though there may be limits on how many devices the DRM scheme will >> permit). >> >> >> Trying to make S/MIME email work in that scenario is futile. The >> sender only tracks one private key for Alice. So Alice has to export >> her private key to all her S/MIME clients. Not only is that terrible >> security practice, it is too much work. Worse, Alice has to repeat the >> process once a year. >> >> That is why I no longer believe that end-to-end is a desirable >> quality. A security requirement that does not consider the cost it >> imposes versus the risks it mitigates is ideology. >> >> >> On Wed, Feb 8, 2012 at 4:52 PM, Stephen Kent =A0wrote: >>> >>> At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote: >>>> >>>> >>>> But authentication works in that scenario because the protocols can >>>> allow >>>> each user to have as many keys as they need. The key is not shared >>>> across >>>> devices, the protocols allow for multiple cards per end user >>>> >>> Sorry, I don't understand you comment. >>> >>> Steve >> >> >> >> > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --=20 Website: http://hallambaker.com/ From stephen.farrell@cs.tcd.ie Wed Feb 8 19:55:11 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6338111E8098 for ; Wed, 8 Feb 2012 19:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P65lq-Ic05MT for ; Wed, 8 Feb 2012 19:55:10 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 013AF11E8094 for ; Wed, 8 Feb 2012 19:55:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E89A3171CFE; Thu, 9 Feb 2012 03:55:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1328759708; bh=15D2W5KCuN0ElY Ko2JQgSE7qqyYCCNt6fcMqvxKS/K0=; b=vMpOcayiQdULSMrjJE8ZLTJ9dNAO7P hEkc66ASavjh9+XtgbIwB0XcOSaM+9W6d1sJrdYFYGHDiYjKoALn8Ep0kX4TlDyo Gdkmbp14yH/rQneEkVqmhQ6zPQCk36WKqqGWWgllPTTJhnTcf30BpzRZ0KPxcXoI L5jQ4/zEiM7Ce/aaGG3tHStkU4qFp29DkW/UhEcSv1ZR9j7zqTHpmBXJ7Rlap0pn 9UTv9vnqhprJEZKbM3oA4ngnRNiGsKdrepBmpBKUZfGms6kIxRI09hUWewh1fzc3 YvKDrQhBrkd9KMnq/Gya0JHC0OQDwB9ijcZCXf0o3lCNSBv9QmdOmblA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id kde3kC76z2Qb; Thu, 9 Feb 2012 03:55:08 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.42.24.40]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 59DE8171CFD; Thu, 9 Feb 2012 03:55:08 +0000 (GMT) Message-ID: <4F33439B.7030406@cs.tcd.ie> Date: Thu, 09 Feb 2012 03:55:07 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Kyle Hamilton References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 03:55:11 -0000 Kyle, I have no idea what you're talking about, sorry. I think the best way to handle that is to go write an I-D describing what you'd like and then send the URL here. (Honestly, in my experience it helps a lot.) S. On 02/09/2012 03:09 AM, Kyle Hamilton wrote: > Once upon a time in the IETF, there was a mandatory-to-implement cipher. > This cipher was the best-selected at the time, using cutting-edge > technologies. > > Time changed. The new mandatory-to-implement cipher came along. > > Why haven't we ever considered that maybe S/MIME doesn't have to be > fully authenticated on first contact? Why haven't we considered that > with only a single certificate chain, the user would first have to > communicate his MUA capabilities to his CA and then not upgrade his mail > client without coordination? > > Instead, we should have a new header in our email. > X-Secure-MIME-Capabilities: > > We could make it contain a base64-encoded representation of what the > Capabilities extension's OCTET STRING would contain. Or we could assign > labels to the various cipher algorithms to make them human-readable. > > Instead of thinking along the lines of "only the named recipient will > get it", why don't we start thinking along the lines of "the destination > mailbox will be able to get it"? > > From there, it becomes fairly easy. "I must ensure that the symmetric > key used to encrypt the message can be decrypted by all of my user > devices and recovery keys." A procmail recipe could perhaps re-send the > message with additional recipient keys. > > At that point, it's "what if I don't have my keys on the device where I > can run procmail?" IMAP becomes a useful tool, as does POP3. They can't > alter messages, but they permit a daemon that can, for example, ensure > that its re(multiply)destined messages make it back into the mailbox > before the original, single-destination message is purged. > > This would also allow for additional commands to be sent from the > devices to the keystore, such as "sign this with my corporate key" or > "send this to aerowolf@gmail.com with the best security you know how to > do". > > The problem is...? > > -Kyle H > > On Wed, Feb 8, 2012 at 6:11 PM, Stephen Farrell > wrote: >> >> >> >> So S/MIME works fine in many cases but does not work well >> between random people connected to the Internet, unlike email. >> That's a pity. >> >> Its not an easy problem though, XMPP have been trying for a >> good while and we don't even seem to have a good solution for >> SIP or Diameter which ought be much easier. >> >> I guess if this discussion lead to a way to manage keys that >> could work at the same scale as email that would be a major >> advance. I don't expect that myself. >> >> And of course, whatever the right answer there (if there >> is one) is maybe very different from how we might manage keys >> for web servers or MTAs or XMPP servers. >> >> Maybe we ought also think about whether or not the same key >> management scheme is right for all those or not as part of >> this too and whether we're able to solve all or just some/one >> of those problems. >> >> Put another way: maybe it'd be better to tighten the focus >> a teeny bit more on this list. Specific suggestions for topics >> welcome. Why not start a new thread with your favourite >> problem that's worth solving and maybe solveable. (Being the >> IETF, we're not very interested in other things in the end:-) >> >> S. >> >> PS: I bet I'm not the only one who can no longer associate >> the subject line with the content. Be good to be better at >> that since it'll help to try move towards some concrete >> outcomes here. >> >> On 02/09/2012 01:22 AM, Phillip Hallam-Baker wrote: >>> >>> Alice has three mobile phones and six laptops. >>> >>> Using embedded keys in those devices for authorization is no problem >>> since each device can have a separate private key and the >>> authentication server tracks the fact that there are nine devices that >>> might authenticate Alice. >>> >>> The same model can even be made to work for confidentiality. Alice can >>> read her DRM protected Kindle content on any one of those devices. >>> (Though there may be limits on how many devices the DRM scheme will >>> permit). >>> >>> >>> Trying to make S/MIME email work in that scenario is futile. The >>> sender only tracks one private key for Alice. So Alice has to export >>> her private key to all her S/MIME clients. Not only is that terrible >>> security practice, it is too much work. Worse, Alice has to repeat the >>> process once a year. >>> >>> That is why I no longer believe that end-to-end is a desirable >>> quality. A security requirement that does not consider the cost it >>> imposes versus the risks it mitigates is ideology. >>> >>> >>> On Wed, Feb 8, 2012 at 4:52 PM, Stephen Kent wrote: >>>> >>>> At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote: >>>>> >>>>> >>>>> But authentication works in that scenario because the protocols can >>>>> allow >>>>> each user to have as many keys as they need. The key is not shared >>>>> across >>>>> devices, the protocols allow for multiple cards per end user >>>>> >>>> Sorry, I don't understand you comment. >>>> >>>> Steve >>> >>> >>> >>> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey > From stephen.farrell@cs.tcd.ie Wed Feb 8 20:05:24 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CE821F8557 for ; Wed, 8 Feb 2012 20:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D--LKD2HGJP8 for ; Wed, 8 Feb 2012 20:05:23 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 618B521F8551 for ; Wed, 8 Feb 2012 20:05:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 572D8171CFE; Thu, 9 Feb 2012 04:05:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1328760321; bh=k1JC5mfSWrhyh0 GjPQUBp28VtVYVD1tnYWB3qMK829I=; b=KkqBo7iAC86vMPzATOK8d0nW9h1Ys6 7l1JUnA84XcdBGdhxq1zfJa3LsB7jTcRSWM3dgX403MDRG2KQNjXw7AqBBmYTdiQ PeP4StNpaRl0Tm8amA36ZNQd52UrjfWfZO49Dk9Ho4AKhjhk/KzhVHtGLW6woo0S nl0mOszaMk+RRswQO63lPVEznvRLII+R+V6gBs1vRNmTIN33dAxLpZGTWgIC/9Jp YF/k5fX5jNkaLCIbHYl0MEN1qzaZsUyToHcydCSzmxXVfvwBY3LB8DHnoPexqOyG imJsAR69cGQSfy7RXRAFHOZAUlyooi0Q+Y6YSA9htPnP5D8WB0601GIg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id lUFCSl--JI8p; Thu, 9 Feb 2012 04:05:21 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.42.24.40]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B1795171CFD; Thu, 9 Feb 2012 04:05:21 +0000 (GMT) Message-ID: <4F334600.9060709@cs.tcd.ie> Date: Thu, 09 Feb 2012 04:05:20 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] focus (Was: Re: Will the real RPF please stand up?) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 04:05:24 -0000 Hi Phill, On 02/09/2012 03:40 AM, Phillip Hallam-Baker wrote: > I think we have a set of requirements that point to a need for three > separable technologies: > > 1) A means by which a site can express the intended security policy > 2) An append only notary service > 3) A means by which a client can obtain security policy curated by a > fourth party > > Each of these components can be designed in stovepipe fashion to only > serve one set of requirements or they can be conceived in slightly > more general form. > > For example, Convergence, SK and CT all involve some form of append > only notary. Such a facility would have far more general applicability > than just addressing public keys. It might well be easier to get a > broad range of parties establishing and supporting the necessary > ecology of notary service providers if they are designed in such a > fashion that they can be used for general purposes. > > > So I will make separate protocol proposals in each area, but Great. That's what's needed for progress to be made here. Send the I-D URLs here as soon as you can! More opinions on your categorisation and its utility would also be good, (e.g. it clearly doesn't try to address the secure-mail-from- all-to-all problem, right?). > I think > what we are designing is going to be easier to deploy if we give some > thought to re-usability of components and dual use. Well... that assumes that there are folks out there who want to re-use stuff. To some extent this space, for now, seems to be a bit more solipsistic. Maybe the people proposing to solve all problems aren't quite as confident as they claim? (...he said deliberately, but honestly, trying to provoke people out of silence:-) S. PS: I do appreciate your being constructive on this. > > > On Wed, Feb 8, 2012 at 9:11 PM, Stephen Farrell > wrote: >> >> >> >> So S/MIME works fine in many cases but does not work well >> between random people connected to the Internet, unlike email. >> That's a pity. >> >> Its not an easy problem though, XMPP have been trying for a >> good while and we don't even seem to have a good solution for >> SIP or Diameter which ought be much easier. >> >> I guess if this discussion lead to a way to manage keys that >> could work at the same scale as email that would be a major >> advance. I don't expect that myself. >> >> And of course, whatever the right answer there (if there >> is one) is maybe very different from how we might manage keys >> for web servers or MTAs or XMPP servers. >> >> Maybe we ought also think about whether or not the same key >> management scheme is right for all those or not as part of >> this too and whether we're able to solve all or just some/one >> of those problems. >> >> Put another way: maybe it'd be better to tighten the focus >> a teeny bit more on this list. Specific suggestions for topics >> welcome. Why not start a new thread with your favourite >> problem that's worth solving and maybe solveable. (Being the >> IETF, we're not very interested in other things in the end:-) >> >> S. >> >> PS: I bet I'm not the only one who can no longer associate >> the subject line with the content. Be good to be better at >> that since it'll help to try move towards some concrete >> outcomes here. >> >> On 02/09/2012 01:22 AM, Phillip Hallam-Baker wrote: >>> >>> Alice has three mobile phones and six laptops. >>> >>> Using embedded keys in those devices for authorization is no problem >>> since each device can have a separate private key and the >>> authentication server tracks the fact that there are nine devices that >>> might authenticate Alice. >>> >>> The same model can even be made to work for confidentiality. Alice can >>> read her DRM protected Kindle content on any one of those devices. >>> (Though there may be limits on how many devices the DRM scheme will >>> permit). >>> >>> >>> Trying to make S/MIME email work in that scenario is futile. The >>> sender only tracks one private key for Alice. So Alice has to export >>> her private key to all her S/MIME clients. Not only is that terrible >>> security practice, it is too much work. Worse, Alice has to repeat the >>> process once a year. >>> >>> That is why I no longer believe that end-to-end is a desirable >>> quality. A security requirement that does not consider the cost it >>> imposes versus the risks it mitigates is ideology. >>> >>> >>> On Wed, Feb 8, 2012 at 4:52 PM, Stephen Kent wrote: >>>> >>>> At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote: >>>>> >>>>> >>>>> But authentication works in that scenario because the protocols can >>>>> allow >>>>> each user to have as many keys as they need. The key is not shared >>>>> across >>>>> devices, the protocols allow for multiple cards per end user >>>>> >>>> Sorry, I don't understand you comment. >>>> >>>> Steve >>> >>> >>> >>> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey > > > From hallam@gmail.com Wed Feb 8 20:14:56 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5D421F85C4 for ; Wed, 8 Feb 2012 20:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgcI1ywhb1lC for ; Wed, 8 Feb 2012 20:14:55 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9242A21F84B6 for ; Wed, 8 Feb 2012 20:14:33 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2082045obb.31 for ; Wed, 08 Feb 2012 20:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TbQy48Di+v5S504HcaMMxHVL69LfQyf5fGkS2Z7qK6c=; b=TvmD5aLyWqxjIp6lSX8VFHiiSidYBSrdJKQ3vBA3wFHy1jL1q5Y8hhdq648AOv1ByM efsoVQD6g0utvIm4xKiVbg6vfGg6vHpbBvLq0go+9rEOsk18DP5vjXZ4TFgw3c9xIbmE OlAq/9gICl7pBkCW0Iwb7G+De/SczOYS1diTA= MIME-Version: 1.0 Received: by 10.182.160.37 with SMTP id xh5mr158796obb.29.1328760873251; Wed, 08 Feb 2012 20:14:33 -0800 (PST) Received: by 10.182.75.138 with HTTP; Wed, 8 Feb 2012 20:14:33 -0800 (PST) In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> Date: Wed, 8 Feb 2012 23:14:33 -0500 Message-ID: From: Phillip Hallam-Baker To: Kyle Hamilton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 04:14:56 -0000 I see this problem as being somewhat off topic but the missing component identified is precisely the same as the one missing for TLS: 1) There is no means for a recipient to express its security policy. 2) There is no infrastructure to allow senders to evaluate expressions of security policy and come to a useful decision on whether or how they should be enforced. Lets get away from the details of how the security policy is expressed. The core missing component in SMIME is that a sender does not know whether or not to use encryption when sending a message. The security policy could be expressed in headers or encoded in DNS records or transported through out of band means. There are pros and cons to each approach, the same ones that come up in the TLS case. So what I would like is a policy language that allows expressions of the fo= rm: example.com YYY "path=3Dwoqioiqoi2jq3roi2jqwoij2q=3D=3D; xxx=3D_http,_smtp" _http.example.com XXX "tls=3Dalways" _smtp.example.com XXX "tls=3Dalways; smime=3Doffered" _smime.example.com XXX "discover=3Dldap,xkms" Meaning, certs offered for example.com will obey the specified certificate path constraint identifying the cert signing cert for the enterprise PKI, there are additional policy specifications for http and smtp both of which say tls is always offered, smime is also available and you can pull the client cert up using either ldap or xkms discovery routes. Now the same information could be presented in HTTP or SMTP headers or exchanged out of band entirely. There are advantages and disadvantages to each distribution mechanism. Which is why my vote would be to have an abstract means of specifying the policy and flow the statements via whatever works. Unlike the usual case of looking at a protocol where people insist that it support PGP keys, SPKI keys and sixteen different public key algorithms because they happen to like 'em, there is a real set of requirements and a real constituency for secure SMTP. And SMTP was the other killer application for the Internet besides the Web. The problem with just having security policy origination is that raw security policy statements tend to have a much higher error rate than is generally tolerable. Particularly during the introductory phase when there is little relying infrastructure. So even though email servers can in theory simply pull up raw statements through the DNS, it is useful to have some background data to help evaluate them. In particular to have reference to some agent that knows the history of that security policy and the number of violations being reported against it. Deploying crypto is actually quite hard for the typical network administrator who is rather more competent in World of Warcraft than PKI to be honest. What almost everyone in IETF land tends to be unable to grasp is that they are members of the technological 1% and that what they find obvious, the 99% will find anything but. So the thing that saved DKIM policy statements was the fact that they are only interpreted by services that are actually very experienced in handling bad data and in fact data that people are intentionally trying to corrupt. On Wed, Feb 8, 2012 at 10:09 PM, Kyle Hamilton wrote: > Once upon a time in the IETF, there was a mandatory-to-implement cipher. > =A0This cipher was the best-selected at the time, using cutting-edge > technologies. > > Time changed. =A0The new mandatory-to-implement cipher came along. > > Why haven't we ever considered that maybe S/MIME doesn't have to be fully > authenticated on first contact? =A0Why haven't we considered that with on= ly a > single certificate chain, the user would first have to communicate his MU= A > capabilities to his CA and then not upgrade his mail client without > coordination? > > Instead, we should have a new header in our email. > =A0X-Secure-MIME-Capabilities: > > We could make it contain a base64-encoded representation of what the > Capabilities extension's OCTET STRING would contain. =A0Or we could assig= n > labels to the various cipher algorithms to make them human-readable. > > Instead of thinking along the lines of "only the named recipient will get > it", why don't we start thinking along the lines of "the destination mail= box > will be able to get it"? > > From there, it becomes fairly easy. =A0"I must ensure that the symmetric = key > used to encrypt the message can be decrypted by all of my user devices an= d > recovery keys." =A0A procmail recipe could perhaps re-send the message wi= th > additional recipient keys. > > At that point, it's "what if I don't have my keys on the device where I c= an > run procmail?" =A0IMAP becomes a useful tool, as does POP3. =A0They can't= alter > messages, but they permit a daemon that can, for example, ensure that its > re(multiply)destined messages make it back into the mailbox before the > original, single-destination message is purged. > > This would also allow for additional commands to be sent from the devices= to > the keystore, such as "sign this with my corporate key" or "send this to > aerowolf@gmail.com with the best security you know how to do". > > The problem is...? > > -Kyle H > > On Wed, Feb 8, 2012 at 6:11 PM, Stephen Farrell > wrote: >> >> >> >> >> So S/MIME works fine in many cases but does not work well >> between random people connected to the Internet, unlike email. >> That's a pity. >> >> Its not an easy problem though, XMPP have been trying for a >> good while and we don't even seem to have a good solution for >> SIP or Diameter which ought be much easier. >> >> I guess if this discussion lead to a way to manage keys that >> could work at the same scale as email that would be a major >> advance. I don't expect that myself. >> >> And of course, whatever the right answer there (if there >> is one) is maybe very different from how we might manage keys >> for web servers or MTAs or XMPP servers. >> >> Maybe we ought also think about whether or not the same key >> management scheme is right for all those or not as part of >> this too and whether we're able to solve all or just some/one >> of those problems. >> >> Put another way: maybe it'd be better to tighten the focus >> a teeny bit more on this list. Specific suggestions for topics >> welcome. Why not start a new thread with your favourite >> problem that's worth solving and maybe solveable. (Being the >> IETF, we're not very interested in other things in the end:-) >> >> S. >> >> PS: I bet I'm not the only one who can no longer associate >> the subject line with the content. Be good to be better at >> that since it'll help to try move towards some concrete >> outcomes here. >> >> On 02/09/2012 01:22 AM, Phillip Hallam-Baker wrote: >>> >>> >>> Alice has three mobile phones and six laptops. >>> >>> Using embedded keys in those devices for authorization is no problem >>> since each device can have a separate private key and the >>> authentication server tracks the fact that there are nine devices that >>> might authenticate Alice. >>> >>> The same model can even be made to work for confidentiality. Alice can >>> read her DRM protected Kindle content on any one of those devices. >>> (Though there may be limits on how many devices the DRM scheme will >>> permit). >>> >>> >>> Trying to make S/MIME email work in that scenario is futile. The >>> sender only tracks one private key for Alice. So Alice has to export >>> her private key to all her S/MIME clients. Not only is that terrible >>> security practice, it is too much work. Worse, Alice has to repeat the >>> process once a year. >>> >>> That is why I no longer believe that end-to-end is a desirable >>> quality. A security requirement that does not consider the cost it >>> imposes versus the risks it mitigates is ideology. >>> >>> >>> On Wed, Feb 8, 2012 at 4:52 PM, Stephen Kent =A0wrote: >>>> >>>> >>>> At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote: >>>>> >>>>> >>>>> >>>>> But authentication works in that scenario because the protocols can >>>>> allow >>>>> each user to have as many keys as they need. The key is not shared >>>>> across >>>>> devices, the protocols allow for multiple cards per end user >>>>> >>>> Sorry, I don't understand you comment. >>>> >>>> Steve >>> >>> >>> >>> >>> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey > > > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > --=20 Website: http://hallambaker.com/ From hallam@gmail.com Wed Feb 8 20:20:43 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057F021E8013 for ; Wed, 8 Feb 2012 20:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgRbmMKCQLfU for ; Wed, 8 Feb 2012 20:20:42 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 183B221E8010 for ; Wed, 8 Feb 2012 20:20:42 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2089697obb.31 for ; Wed, 08 Feb 2012 20:20:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4B/Mk33+HS4YClDaA4gTW592IhVxqYKt3roTcFM3fOQ=; b=h7+5Wc6C17jWFt2rQzZV8mk+nRDqnPU4y0Yr1YKQ89iZA/rrnGdE+mrj4idDWOvkVY M9zRYYubhqefuE9uQScQze5Fxan2b60CnUoDf/zAp5utit9AkbVAZSx7VUcolQpOY8fd IvJZvT3JQGooZKHHEMSXgZCBKwhGdbrLO/B40= MIME-Version: 1.0 Received: by 10.182.160.37 with SMTP id xh5mr177992obb.29.1328761241760; Wed, 08 Feb 2012 20:20:41 -0800 (PST) Received: by 10.182.75.138 with HTTP; Wed, 8 Feb 2012 20:20:41 -0800 (PST) In-Reply-To: <4F334600.9060709@cs.tcd.ie> References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> <4F334600.9060709@cs.tcd.ie> Date: Wed, 8 Feb 2012 23:20:41 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" Subject: Re: [therightkey] focus (Was: Re: Will the real RPF please stand up?) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 04:20:43 -0000 At the moment I have * An Internet draft for expressing security policy in the form of DNS statements. * A draft of a white paper describing a general solution framework. * Some proprietary protocols that implement the client-broker interface * An aspiration to write a notary protocol ID. I guess the sensible thing to do is probably to focus on getting out drafts for the security policy origination and the client-broker interface. On Wed, Feb 8, 2012 at 11:05 PM, Stephen Farrell wrote: > > Hi Phill, > > > On 02/09/2012 03:40 AM, Phillip Hallam-Baker wrote: >> >> I think we have a set of requirements that point to a need for three >> separable technologies: >> >> 1) A means by which a site can express the intended security policy >> 2) An append only notary service >> 3) A means by which a client can obtain security policy curated by a >> fourth party >> >> Each of these components can be designed in stovepipe fashion to only >> serve one set of requirements or they can be conceived in slightly >> more general form. >> >> For example, Convergence, SK and CT all involve some form of append >> only notary. Such a facility would have far more general applicability >> than just addressing public keys. It might well be easier to get a >> broad range of parties establishing and supporting the necessary >> ecology of notary service providers if they are designed in such a >> fashion that they can be used for general purposes. >> >> >> So I will make separate protocol proposals in each area, but > > > Great. That's what's needed for progress to be made here. Send > the I-D URLs here as soon as you can! > > More opinions on your categorisation and its utility would also > be good, (e.g. it clearly doesn't try to address the secure-mail-from- > all-to-all problem, right?). > > >> I think >> what we are designing is going to be easier to deploy if we give some >> thought to re-usability of components and dual use. > > > Well... that assumes that there are folks out there who want to > re-use stuff. To some extent this space, for now, seems to be > a bit more solipsistic. Maybe the people proposing to solve all > problems aren't quite as confident as they claim? (...he said > deliberately, but honestly, trying to provoke people out of > silence:-) > > S. > > PS: I do appreciate your being constructive on this. > > >> >> >> On Wed, Feb 8, 2012 at 9:11 PM, Stephen Farrell >> =A0wrote: >>> >>> >>> >>> >>> So S/MIME works fine in many cases but does not work well >>> between random people connected to the Internet, unlike email. >>> That's a pity. >>> >>> Its not an easy problem though, XMPP have been trying for a >>> good while and we don't even seem to have a good solution for >>> SIP or Diameter which ought be much easier. >>> >>> I guess if this discussion lead to a way to manage keys that >>> could work at the same scale as email that would be a major >>> advance. I don't expect that myself. >>> >>> And of course, whatever the right answer there (if there >>> is one) is maybe very different from how we might manage keys >>> for web servers or MTAs or XMPP servers. >>> >>> Maybe we ought also think about whether or not the same key >>> management scheme is right for all those or not as part of >>> this too and whether we're able to solve all or just some/one >>> of those problems. >>> >>> Put another way: maybe it'd be better to tighten the focus >>> a teeny bit more on this list. Specific suggestions for topics >>> welcome. Why not start a new thread with your favourite >>> problem that's worth solving and maybe solveable. (Being the >>> IETF, we're not very interested in other things in the end:-) >>> >>> S. >>> >>> PS: I bet I'm not the only one who can no longer associate >>> the subject line with the content. Be good to be better at >>> that since it'll help to try move towards some concrete >>> outcomes here. >>> >>> On 02/09/2012 01:22 AM, Phillip Hallam-Baker wrote: >>>> >>>> >>>> Alice has three mobile phones and six laptops. >>>> >>>> Using embedded keys in those devices for authorization is no problem >>>> since each device can have a separate private key and the >>>> authentication server tracks the fact that there are nine devices that >>>> might authenticate Alice. >>>> >>>> The same model can even be made to work for confidentiality. Alice can >>>> read her DRM protected Kindle content on any one of those devices. >>>> (Though there may be limits on how many devices the DRM scheme will >>>> permit). >>>> >>>> >>>> Trying to make S/MIME email work in that scenario is futile. The >>>> sender only tracks one private key for Alice. So Alice has to export >>>> her private key to all her S/MIME clients. Not only is that terrible >>>> security practice, it is too much work. Worse, Alice has to repeat the >>>> process once a year. >>>> >>>> That is why I no longer believe that end-to-end is a desirable >>>> quality. A security requirement that does not consider the cost it >>>> imposes versus the risks it mitigates is ideology. >>>> >>>> >>>> On Wed, Feb 8, 2012 at 4:52 PM, Stephen Kent =A0 =A0wrot= e: >>>>> >>>>> >>>>> At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote: >>>>>> >>>>>> >>>>>> >>>>>> But authentication works in that scenario because the protocols can >>>>>> allow >>>>>> each user to have as many keys as they need. The key is not shared >>>>>> across >>>>>> devices, the protocols allow for multiple cards per end user >>>>>> >>>>> Sorry, I don't understand you comment. >>>>> >>>>> Steve >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> therightkey mailing list >>> therightkey@ietf.org >>> https://www.ietf.org/mailman/listinfo/therightkey >> >> >> >> > --=20 Website: http://hallambaker.com/ From ryan.hurst@globalsign.com Wed Feb 8 20:58:47 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A0621E8017 for ; Wed, 8 Feb 2012 20:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du89D0eFZEbm for ; Wed, 8 Feb 2012 20:58:46 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4AC21E8016 for ; Wed, 8 Feb 2012 20:58:45 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so1256416pbc.31 for ; Wed, 08 Feb 2012 20:58:45 -0800 (PST) Received: by 10.68.226.98 with SMTP id rr2mr1715270pbc.115.1328763525769; Wed, 08 Feb 2012 20:58:45 -0800 (PST) Received: from rmhlaptop ([50.46.232.231]) by mx.google.com with ESMTPS id r9sm3422453pbi.6.2012.02.08.20.58.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 20:58:45 -0800 (PST) From: "Ryan Hurst" To: "'Stephen Farrell'" , "'Ben Laurie'" References: <008d01cce5f1$2b322f50$81968df0$@globalsign.com> <07b401cce685$a38fc950$eaaf5bf0$@globalsign.com> <087101cce692$75ca07d0$615e1770$@globalsign.com> <4F32F4BA.1000307@cs.tcd.ie> In-Reply-To: <4F32F4BA.1000307@cs.tcd.ie> Date: Wed, 8 Feb 2012 20:58:43 -0800 Message-ID: <02d201cce6e7$7feb4260$7fc1c720$@globalsign.com> X-Mailer: Microsoft Outlook 14.0 MIME-Version: 1.0 Thread-Index: AQL4mjWmSaqaob+72JTbo+7ebzds9wGmTpSgASWWThUBSY1IVAFkCrJ8ANDXCHMCq78FnZOU549w Content-Language: en-us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02CD_01CCE6A4.70F8F290" X-Gm-Message-State: ALoCoQkYvNVfhUj9QcXiUs23XghSB2Vo7ncyqCX0bZB9AF3NnsyB/cD3pTyjt8JQ8Fz+a35DaSPD Cc: 'Joe St Sauver' , therightkey@ietf.org, 'Stephen Kent' Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 04:58:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02CD_01CCE6A4.70F8F290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stephen, I agree with all your points on OBC, especially the ability to register multiple keys for the same user; keys are cheap and if we used a primary key like an email address instead of a key this becomes easier; of course as we go down this path OBC looks like more like BrowserID implemented tied into the TLS stack (which has positive KFD properties). As for the signaling topic, Phillip is often discussing the need to express policy in a secure way; DNS and DNSSEC often come up in those conversations -- one could imagine expressing that signaling policy there also. As I write this though it feels odd to see a solution span so many layers, so intimately; that said I have seen (and done) worse ;) On the topic of logging out, I think it's mainly a 99% vs. 1% problem, we being the technological 1% understand the value of closing the browser most users do not, they have been programed for two decades that if they want to stop someone from using their account to logout, not to close all applications and starting all over again. It's common for users to say they feel "trapped" or "lost" when searching for the thing they know must be there and is not, or when it's there but doesn't do what they expect. Having a "logon" concept that has no explicit "logoff" that maps to their views and expectations creates a bad user experience and encourages bad behavior - staying on forever. Ryan -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, February 08, 2012 2:19 PM To: Ben Laurie Cc: Ryan Hurst; Joe St Sauver; therightkey@ietf.org; Stephen Kent Subject: Re: [therightkey] Client Certificate Usability (was RE: Will the real RPF please stand up?) On 02/08/2012 07:19 PM, Ben Laurie wrote: > On 8 February 2012 18:49, Ryan Hurst wrote: > >> One of the things I like about BrowserID as an approach is that I >> agree with others that the portability of key material in today's >> world is important and by them including the vetting of the ownership >> of an email in their key provisioning workflow they kind of address this problem. >> On the OBC theme, I do like that. (Though I think signalling it via an HTTP authentication scheme would be an improvement as well but that's a detail.) One thing that could be done with OBC would be to not try to move the private keys, but rather provide a standard way to bind different OBC public keys on the user's different devices to the same server account. So, e.g. to associate two devices to the same account the user would be sent to https://example.com/.well-known/obc-bind and after TLS mutual auth would be shown e.g. a short-lived code that could then be entered on a form at the same URL accessed from another device. The UI for that needn't be standard so servers could innovate fairly freely there I think. If the user can bind various devices to the same server account then I think a bunch of account registration and recovery options become available without having to ever move a private key and also without having to bake the registration part into the TLS authentication scheme. It still doesn't do logout though, but personally I don't really get why that's such a deal. I suspect that if we did have logout then malware would just adapt and overall we'd not be that much better off. Maybe I don't get the real requirement there though. > Then you might like the work I did on portability of key material: > http://www.links.org/files/nigori-overview.pdf. I don't get how this differs at all from any centralised login service nor, if its just a key store, why it'd prove any more popular than sacred was, though maybe that's long enough ago that things have changed enough (the EKE patent expired in the meantime at least;-) S. ------=_NextPart_000_02CD_01CCE6A4.70F8F290 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCCA3Uw ggJdoAMCAQICCwQAAAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7mmY3O o+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsurHExwB6E9 CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8GPIhpWypNxadU uGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounICjjr8iQTT3NUkxOF Ohu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjIGSvRRqpI1mQq14M0/ywq wWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZIhvcNAQEFBQADggEB ANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16qEUi25Qijs8o9YU3TRgmzPsOg42NVG/K6 76054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeYBN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8s uWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUMHaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRW MZXQZ4mFK/lspl1GnQyqguSZUd1wt9tWPWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY 24GzBBzFH6SAbxUgyd4MiAod1mZV4vxIySkmaeAwggQWMIIC/qADAgECAgsEAAAAAAEvTuEvUjAN BgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQ MA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMSR2xvYmFsU2lnbiBSb290IENBMB4XDTExMDQxMzEw MDAwMFoXDTE5MDQxMzEwMDAwMFowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFrQfk17PgSfd0iUWlft7kTRid3FDvjE4FvPuR0F34M tfQs5AyNU9TcMCAov26OEf5mEeRRFsfdf/3hNBJQv/PYmOxpC9LQ2rJlceEzl566q7M4lHMRDz6h 0RPMeDYbQSu/vKNJ7DCCTANYMmdhQOU6NhMNQQbr6L7wyfjbmt6jgjQTbvvAPnjaSZVZ5bv6ge/l 1mj17VDJbCIpMQ/oERBVVIGBOFcwbi2tpJINFS3dPV5BNnHkQ5umIEQE7g5OqIFMl+Di8QhiCRfM oumd+zNMHpgwOlH39BLqncA0HeR8Bv63q51I7dYKy3QMavAcMsEUYNHhR5hPkoYacjtxYvsCAwEA AaOB5TCB4jAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUPxXS bXwv5zGeQwoGqJRsLDvF7mUwRwYDVR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBz Oi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC5jcmwwHwYDVR0jBBgwFoAUYHtmGkUNl8qJUC99BM00 qP/8/UswDQYJKoZIhvcNAQEFBQADggEBAENzecykzEkxAxxhQIHf4LvdSm/AMTx4I6vu3YX+5pAo pzKqqy2otlzq8/Aj+twT2gMe6BjlASNDMgEgRpOc3o/S96B7YhdgS9NZtbAZ0/K0MU9giXf/o6o1 JdKdnsPE9x0smra7KKBrw8H9NMggdiR0zb7UMTTvLesf/tOPANUPtIu7n9J058qyS4w9OM4S/Pcr XrWbKZbTqSVWG5sIhY6uj8bHVDbYVA5nv/aTi5ig50FNKVvyRMC7Nk2AgTSsHYEhgJPP8/rNkgpb SiBtFIeVOreo+yT7sDT/85yJsDK5RwydWKVtK5Bdjxq2lQoAwX/XTgfiCKZ8B3yIviw/niEwggUG MIID7qADAgECAhIRIW+uNPxdwlMR7qsGU+m0guUwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29u YWxTaWduIDIgQ0EgLSBHMjAeFw0xMjAxMjMxNjM2NTlaFw0xNTAxMjMxNjM2NTlaMIGUMQswCQYD VQQGEwJVUzEWMBQGA1UECBMNTmV3IEhhbXNwaGlyZTETMBEGA1UEBxMKUG9ydHNtb3V0aDEZMBcG A1UEChMQR2xvYmFsU2lnbiwgSW5jLjETMBEGA1UEAxMKUnlhbiBIdXJzdDEoMCYGCSqGSIb3DQEJ ARYZcnlhbi5odXJzdEBnbG9iYWxzaWduLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALgBJJO9q+awVAChvrS6RJLA4Av2dP+z32W01QIB/l88fmM1x4wrFpCx7aaI6ZFEhdrKRyrW n9NsjvRm1x7fyvaZs7CoMcc9WLXcbEkTJRdaBpEG14My7k4bJY0bWRyFWwZaluy1PRni/SZ3mbUF gWfEHbR5snI5HaVcPGwUrbyecpX7l4yPvpTwGk9DhIIfvJMwbrLRdewHdwKsEqvajdM5iAQq/6g2 dtqgy3dTEy32dJ/2PIiyGOp+dPkB7DcJQ0xq07nmDkVdd0i6QDB6DVhJvWWzTmpbexbTRPd3t1Cz 3/s27EKD8DZ6WZUlKjLz4wtHwlIUR/9oyCM79PIuD+MCAwEAAaOCAY8wggGLMA4GA1UdDwEB/wQE AwIFoDBNBgNVHSAERjBEMEIGCisGAQQBoDIBKAowNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cu Z2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wJAYDVR0RBB0wG4EZcnlhbi5odXJzdEBnbG9iYWxz aWduLmNvbTAJBgNVHRMEAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8E PDA6MDigNqA0hjJodHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMmcy LmNybDBVBggrBgEFBQcBAQRJMEcwRQYIKwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2ln bi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMmcyLmNydDAdBgNVHQ4EFgQUVaIQJ7T8vvZ5Vipx ZictXpJKPOEwHwYDVR0jBBgwFoAUPxXSbXwv5zGeQwoGqJRsLDvF7mUwDQYJKoZIhvcNAQEFBQAD ggEBACFCLqEs9652Z/cgEXggPMK9EjQVph0Ep+mtKT8fQ8N5ri+mwttakDS3RJqKOIli3EqOUzhs 937ZyFvt6Nq0N3KtkjOYNXKrhzfT/EyeKcYqiSlgDXX9V76LZ2+O6W7rmpqyu1BEbJsC65nruWun 8rc4wWCNXk0LcAdgvO81TgPBzhBDUFow6DorNhKspsAFFlqN+ukL26J4+y/uYMhcvH+2gE/FY2Vr m8mbkOtl2fu4d28EITqQzKRs4s3mmYQrRQiXAqHpCLlcPSnOVWQRmWIWQEwmC5t394XvF6DtMo9Y LnHI4Wn1J0yiUkzstMLfCdI7d+sEB6/6r+caz1fHK+wxggOYMIIDlAIBATBqMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNv bmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TAJBgUrDgMCGgUAoIICAzAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAyMDkwNDU4NDNaMCMGCSqG SIb3DQEJBDEWBBRaaeOs4KAyS4+N110YLFhM8j4AqTB5BgkrBgEEAYI3EAQxbDBqMFQxCzAJBgNV BAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBl cnNvbmFsU2lnbiAyIENBIC0gRzICEhEhb640/F3CUxHuqwZT6bSC5TB7BgsqhkiG9w0BCRACCzFs oGowVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUds b2JhbFNpZ24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMIGrBgkq hkiG9w0BCQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglg hkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3 DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0G CSqGSIb3DQEBAQUABIIBAFeVQT7JSsdPXqEXlDED9mLzpxnB4rzpvThefNdrxP6pjUa3HhaT/DF3 2ldoZB4ut/B/D/kNTQvrim51fJXgEsme4XDKVXDRnA0nRsFbJww2ltPGQDVXLYdOlB22vqonPY+Z EkVUFmMhJKqvZBTXnxRQI82fXQW10u18BIIxSvmtaFiYvdDN0cNz+Gd4hU1/ojWNxKefCliDHi0f 6qir2tFHyWAb1CUNoSJCh54UBzcEPMraAFxi4u9voEuMncnUhqhBUiOxq/Z2bVT9ocvJcCJZEVN3 hluDv6zVubWOZdj+PvP/lRGSKM5pOcrZ3RYRymjbM1GwXBpow7z1mbQqaEAAAAAAAAA= ------=_NextPart_000_02CD_01CCE6A4.70F8F290-- From nico@cryptonector.com Wed Feb 8 21:35:40 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCA611E8091 for ; Wed, 8 Feb 2012 21:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ROaHYHPP-tz for ; Wed, 8 Feb 2012 21:35:38 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id D71EA21F8559 for ; Wed, 8 Feb 2012 21:35:29 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 0C1C42AC06A for ; Wed, 8 Feb 2012 21:35:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=ZW/6YI6VZY5JsSkmonoGQ 752gnWaCw2TdpPcPkti3pIqiYCUJ+y7mU5ma/K4+VcmKM7grTm5X8g7w+pEOi/N2 VpMj/0+A1hlRQW1v22fWe+TaTz2P0gqlE8YAadtwnZJ6BFKM5etd+KPo09rYjzAx cKbCvTNh93+WgAoHmHua1k= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=yHhatRDgdvl4wS5d5JpF LKFtkOE=; b=HqfxdSE/AOp6XjbS32BIvXdWaOI2ZOT6giLRDo7H7m2SAfeD3A7Y mr1E2SKoot7cJNQy45tw5p/GP+h7MKn6f2gNwWyBmQqb09NHfFEb8iJrllwoIs0Q 6GXaTYBJivSkYBxYZs7LAXoTYnGwVy7yCHgo9pZUiNRatEq3HM/9AVE= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id F056A2AC00D for ; Wed, 8 Feb 2012 21:35:28 -0800 (PST) Received: by dakl33 with SMTP id l33so1201163dak.31 for ; Wed, 08 Feb 2012 21:35:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.232.103 with SMTP id tn7mr2173009pbc.74.1328765728701; Wed, 08 Feb 2012 21:35:28 -0800 (PST) Received: by 10.68.136.4 with HTTP; Wed, 8 Feb 2012 21:35:28 -0800 (PST) In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> Date: Wed, 8 Feb 2012 23:35:28 -0600 Message-ID: From: Nico Williams To: Kyle Hamilton Content-Type: text/plain; charset=UTF-8 Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 05:35:40 -0000 E-mail is not an online protocol between two MUAs. When you send an e-mail your MUA is not talking directly to the recipient's MUA, and there are no automated replies except for vacation replies. Thus in a cold-call e-mail send you have no knowledge about the recipient's MUA's capabilities. You can only sign your e-mail and hope that the recipient can validate the signature. If you know the recipient's public key and can derive some knowledge about the recipient's MUA's capabilities from that public key and surrounding material, such as a certificate or other metadata, then you can send signed and encrypted e-mail to them. The required metadata -the recipient's MUA's capabilities- are found where the recipient's public key is found. That metadata has to be somewhere, but e-mail headers isn't that somewhere. This limits your and your correspondents' ability to switch to other MUAs: they'd better support the capabilities that you've advertised with your keys. Sure, we could build a TLS-like protocol out of e-mail, if MUAs knew how to speak to each other the mail network. You'd say you want to send e-mail to Joe@some-domain.example and your MUA could send a specially crafted e-mail that Joe's MUA understands as a ClientHello (and which Joe wouldn't see, as it would do Joe no good to see it), responding with ServerHello and so on, and then you have a session key that you can use to send encrypted mail to Joe. And then we'd need to negotiate cipher suites and such just like TLS. But that's not how e-mail works. You send an e-mail, and hopefully it gets there, and there's no automatic ping-pong until keys are established, there's only that one e-mail. That's why S/MIME and PGP work the way they do. There are reasons why S/MIME and PGP haven't become killer apps (and someone who knows much more about them than I can lay them out), but lack of a header by which to communicate MUA capabilities is not one of them -- we would have solved that long ago if it had been. Nico -- From dkg@fifthhorseman.net Wed Feb 8 21:49:05 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B96A21F84A3 for ; Wed, 8 Feb 2012 21:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sb1BL-5SgzGB for ; Wed, 8 Feb 2012 21:49:04 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id AD45821F84A1 for ; Wed, 8 Feb 2012 21:49:04 -0800 (PST) Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 02ACCF970 for ; Thu, 9 Feb 2012 00:49:02 -0500 (EST) Message-ID: <4F335E75.5060805@fifthhorseman.net> Date: Thu, 09 Feb 2012 00:49:41 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20120125 Icedove/9.0.1 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 05:49:05 -0000 On 02/08/2012 08:22 PM, Phillip Hallam-Baker wrote: > Worse, Alice has to repeat the process once a year. Why would Alice have to repeat the process once a year? Are you suggesting she has to replace her decryption key every year? Does this have to do with the "repeat customer" lock-in model operated by modern CAs where certificates are given artificially-short lifespans? Even in the face of that kind of tactic, why wouldn't Alice just get an updated certificate from the same key and avoid having to re-key all her devices? The only thing Alice needs for decryption is the secret key material; she doesn't have to synchronize certificates at all for this use case. --dkg From hallam@gmail.com Thu Feb 9 05:16:19 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCAFD21F8567 for ; Thu, 9 Feb 2012 05:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W32y5ML9trR4 for ; Thu, 9 Feb 2012 05:16:18 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E54121F8543 for ; Thu, 9 Feb 2012 05:16:17 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2822550obb.31 for ; Thu, 09 Feb 2012 05:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oLEmD94M8r8XVUeSGXLtrcmm+bdMb//A9kY9dwRTmhM=; b=ffJOQmjtGnCgijHNnvsC/b/7CDQL9qQIkH8SD/sjpWNfAv9hxDeJDOEg82/UzYHIDQ KfmxLk77uIVyZ+4KggxIrgTcONwqFFTCj7cR4Lm6PPNAoG/nfTBJ3mytWCO3aFJXAD+H AxTuL773orudYPwKJkuNGsXknU8wJqT/QQh60= MIME-Version: 1.0 Received: by 10.182.160.37 with SMTP id xh5mr1670316obb.29.1328793376935; Thu, 09 Feb 2012 05:16:16 -0800 (PST) Received: by 10.182.75.138 with HTTP; Thu, 9 Feb 2012 05:16:16 -0800 (PST) In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> Date: Thu, 9 Feb 2012 08:16:16 -0500 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" , Kyle Hamilton , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 13:16:19 -0000 Agreed, but! Let us drop the end to end ideology in the dustbin and accept that email is an MTA to MTA protocol, or to be more precise it is three protocols: MUA -> MTA: SMTP/SUBMIT or HTTP MTA -> MTA: SMTP MTA -> MUA: POP / IMAP or HTTP Note the presence of HTTP. People have been discussing email as if SMTP =3D=3D email. In fact a huge proportion of email travels over HTTP instead of SUBMIT or POP/IMAP and quite a bit flows over HTTP alone (all email from one gmail account to another, or hotmail, yahoo, yadda yadda). For Alice and Bob there are many possible paths: I very often start writing an email message on one machine and continue on another. In the course of a typical day I use a minimum of one PC, one Macbook, one iPhone and my work iPad. So for me it is actually quite usual for me to start writing an email on the Mac and continue on the PC. I typically read the messages on whichever one of the four machines is close at hand. So the arity of the relationships is: MUA -> MTA: Many -> 1 MTA -> MTA: 1 -> 1 MTA -> MUA: 1-> Many Now a good email setup should of course have multiple MTAs. But they should have a setup that makes them look like a single logical unit. There are many mail servers for example.com but only one logical mail service. So now we see why security policy driven by MUA published security policy is going to fail: there is no consistency in the MUA loop. I read mail on four separate devices. They have no way to communicate between themselves to negotiate a common security policy and I certainly would not want them to. Conclusion: 1) Security policy is a property of MTAs and not MUAs and hence of domains and not accounts. 2) We need a security policy layer for the internet as a whole and not just for what people imagine to be the 'Web' or 'email' portions thereof. This is a problem caused by stovepipe thinking and non-my-problemism. A SUBMIT MTA should tell the MUAs that it serves how to connect to it. That is the port, protocol, use of TLS and certificate chain. An SMTP server should likewise tell MTA clients what its security policy is (use of STARTTLS, use of certificate chain, availability of SMIME/PGP), authentication requirements. The MTA -> MUA loop is interesting in that the directionality of the protocol changes. The data has been flowing from client to server, now it flows from a server to a client: Client -> [Server : Client] -> [Server : Server] -> Client So the POP or IMAP service would again publish policy telling clients to connect. Not that this is also a usability win. No more check boxes to tick in order to get the configuration params right. Add the capability for MTAs to publish policy and we can establish a hop-by hop security mechanism that covers each of the three mail interactions in three separate end-to-end sessions. Getting back to the bigger problem, no this is not solving all the problems we are seeing in the Web space. But it is solving a pretty big one there. Web security is harder to improve than email security because we already have quite a bit of Web security and very little email security. On Thu, Feb 9, 2012 at 12:35 AM, Nico Williams wrot= e: > E-mail is not an online protocol between two MUAs. =A0When you send an > e-mail your MUA is not talking directly to the recipient's MUA, and > there are no automated replies except for vacation replies. > > Thus in a cold-call e-mail send you have no knowledge about the > recipient's MUA's capabilities. =A0You can only sign your e-mail and > hope that the recipient can validate the signature. > > If you know the recipient's public key and can derive some knowledge > about the recipient's MUA's capabilities from that public key and > surrounding material, such as a certificate or other metadata, then > you can send signed and encrypted e-mail to them. =A0The required > metadata -the recipient's MUA's capabilities- are found where the > recipient's public key is found. =A0That metadata has to be somewhere, > but e-mail headers isn't that somewhere. =A0This limits your and your > correspondents' ability to switch to other MUAs: they'd better support > the capabilities that you've advertised with your keys. > > Sure, we could build a TLS-like protocol out of e-mail, if MUAs knew > how to speak to each other the mail network. =A0You'd say you want to > send e-mail to Joe@some-domain.example and your MUA could send a > specially crafted e-mail that Joe's MUA understands as a ClientHello > (and which Joe wouldn't see, as it would do Joe no good to see it), > responding with ServerHello and so on, and then you have a session key > that you can use to send encrypted mail to Joe. =A0And then we'd need to > negotiate cipher suites and such just like TLS. =A0But that's not how > e-mail works. =A0You send an e-mail, and hopefully it gets there, and > there's no automatic ping-pong until keys are established, there's > only that one e-mail. > > That's why S/MIME and PGP work the way they do. =A0There are reasons why > S/MIME and PGP haven't become killer apps (and someone who knows much > more about them than I can lay them out), but lack of a header by > which to communicate MUA capabilities is not one of them -- we would > have solved that long ago if it had been. > > Nico > -- > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --=20 Website: http://hallambaker.com/ From hallam@gmail.com Thu Feb 9 07:27:39 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228E021F8319 for ; Thu, 9 Feb 2012 07:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRoHgAiqjdVX for ; Thu, 9 Feb 2012 07:27:34 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E196221F8588 for ; Thu, 9 Feb 2012 07:27:33 -0800 (PST) Received: by obbwd15 with SMTP id wd15so2988990obb.31 for ; Thu, 09 Feb 2012 07:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=HRn4e7SKYtQIyC0bLTJFdDGgsoje2qBMZ8nBmtmHU3U=; b=t/NWTX7zFUznhZhMWmvut9TB7mkq4Jr7btyd2iw9Z05OwyUNMaZGYn5JzFmImDcmDV fvbE/jjCpK0TrlAEEABVj/84lMS6VONl+TjWjUGKYBoEso+PqN+6qiqxG2cNOEbq1F0f A3trq+Zns37fhvwA1l0mhozi4UqmK9ZXink9A= MIME-Version: 1.0 Received: by 10.182.160.37 with SMTP id xh5mr2374206obb.29.1328801252893; Thu, 09 Feb 2012 07:27:32 -0800 (PST) Received: by 10.182.75.138 with HTTP; Thu, 9 Feb 2012 07:27:32 -0800 (PST) Date: Thu, 9 Feb 2012 10:27:32 -0500 Message-ID: From: Phillip Hallam-Baker To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [therightkey] Notes on notaries X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 15:27:39 -0000 One component that appears in three of the proposals input to this discussion is an 'append only' notary. While the precise role and implementation of the notary changes there are some common features: * Use of the Harber/Stornetta catenate certificate approach (aka hash chains, Merkle trees etc) * Some notion of 'crowdsourcing' or 'peering' of notaries Note that the original Harber/Stornetta patent has expired. There may be patents still outstanding on specific optimizations but I don't see any of those as being essential. None of the proposals seem to me to be dependent on a particular notary implementation. Some are pretty sketchy when it comes to details. I think this is a feature that could and should be separated out as a separate problem. The uses of a general purpose append-only notary are very significant: * Proof of the date that evidence was collected for legal purposes * Proof that a specific set of contract terms existed on a specific date * Proof that a Web site delivered specific content on a specific date The reason I think these additional purposes matter is that I think that a notary service needs to be done right and will require infrastructure. Specifically, government supported infrastructure. I am very happy with the idea of walking into NIST or the FBI or the UK Home office and putting out a case for the reason why USGov or HMG should invest a $1 million or so on setting up a reference notary for their country. I don't think the same case can be made for the PKI proposals being made. The reason I want to have government notaries in the mix is that a government service provides authority that is recognized and understood by the courts. If Ms Defendant is disputing the digital evidence being presented by the Metropolitan police claiming it was modified after they caught her, the court is going to accept a digital notary stamp that is ultimately validated by a notary service run by HMG much more easily than one just run by Comodo Inc. In the first case the evidence is going to be presumed valid without further consideration, in the second it is highly likely that expert witnesses etc. will be required. Such a notary service would be the online equivalent of a time service and would need to be structured in a similar fashion with 'tiers' of service: Tier 1: Master reference notaries run by national laboratories Tier 2: Service notaries run by commercial entities and universities Tier 3: Enterprise notaries that serve a specific organization Notaries in the top tier would cross-notarize on a regular (e.g. hourly) basis. Notaries in tier 2 would sync with one (or more) tier 1 notaries on a regular basis Notaries in tier 3 would sync with tier 2. I would expect that at least one major university (e.g. CMU, MIT, whatever) would be willing to support the open source community by running an open notary service. At least one entity in the system should be introducing a stream of random data into the notarization stream. Such an infrastructure would provide a means of fixing a digital notarization event between two fixed points in the timeline as follows: First we have to recognize that there is a difference between 'ordinary' notarization in which a user gets a single document stamped and 'meta' notarization which is performed between peers. Ordinary Notarization: Let the document to be notarized be D, the time be t and the current witness value from the chosen tier 1, 2, 3 notaries be V1t, V2t, V3t and the next witness values as V1t', V2t', V3t', the ones after that Vt'', etc. The user submits to the Tier 3 notary, H(D), [identifier of the meta-timelines fixation is requested against] Tier 3 notary replies with a URL and a 'delivery date' (which will be a function of the meta-timelines fixed) After the delivery date (typically an hour in the future) the user can retrieve a proof chain that fixes H(D) with respect to V1t, V2t, V3t and V3t', and either a proof or a reference to a proof fixing V3t' with respect to V2t'' and V2t'' with respect to V1t'''. The protocol could be adapted to support multiple second and first tier notaries, but this is complexity without any real benefit. It does not actually provide any additional security for reasons that will be explained later. The most efficient data structure to use at this level is probably a Merkle tree. Delaying the delivery of the proof means that the notary can even choose the optimal approach after the number of items to be notarized is known. Meta Notarization Meta Notarization is the process of fixing tier 1 notaries against each other. Any notary that engages in the peer notarization is a tier 1 notary by definition. (this may not be a necessary restriction, can come back to that). Tier 1 notaries may participate in one or more meta-timelines. Each meta timeline produces a stream of public witness values that is archived by every member of the timeline. Each meta-timeline incorporates at least one purely random data source. For convenience, all the members of a timeline use the same inputs to the hash function in the same order. The precise mechanism for doing this does not matter so much as that they all arrive at the same result. The simplest implementation would be for one party to act as the meta notary but politics is likely to intervene and require that this function is performed on a rotating basis. Example: Alice wishes to fix document X according to the 'Internet' meta-timeline 1) Alice submits H(X) to her notary 2) Some time later, notary responds with the static proof chain When Alice needs to use the proof to convince Bob she presents the static proof chain and either Alice or Bob pulls the current value of the 'Internet' timeline witness values. The most efficient data structure for this layer is probably to use a skip list. But efficiency 'probably' does not actually matter. The advantage of this structure is that the problem is divided into two, there is a static component that is immediately fixed and a variable component that can be cached to a great degree. If we are thinking of applying this approach to Internet certificates then it is really not unreasonable for every client that chooses to validate this data locally to download a few Kb of meta timeline data every single day. Security analysis One of the interesting features of the system is that the notaries are trustworthy but not trusted. The scope for defection by a notary is very limited. It is desirable to authenticate communications with the notaries but only to prevent a third party performing a denial of service attack by introducing bogus data. Once a notary has delivered the proof and the client has verified that it correctly ties to the meta-timeline, the notary becomes irrelevant. There is nothing that the notary can do to defect. The notary cannot even perform a denial of service attack. The ability of the tier 2, 3 notaries to defect is thus bounded in time to the interval between the request being made and the response being verified. The arguments for meta-notaries are a little more complex but again the notary can only defect by refusing service or corrupting Any client relying on verifying notary data is going to have to be capable of adapting to the fact that the chosen meta-timeline might disappear at a future date so the denial of service attack is not particularly worrying. Meta-Timelines can change over time and the protocol needs to be able to cope with this. Specifically a meta-timeline can fork if some parties decide to leave. But this just requires that the successor timelines to agree on clear identifiers so that they do not become ambiguous. Timelines can also merge. All this requires is for the last witness value of one meta timeline to be input to another. Which is the way that a Meta-Timeline should be decommissioned in an orderly fashion. In fact, it is desirable for there to be multiple meta-timelines and for them to fix themselves against each other on a regular basis in case of a sudden and unexpected failure or breach. -- Website: http://hallambaker.com/ From nico@cryptonector.com Thu Feb 9 07:34:35 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA9A21F86FC for ; Thu, 9 Feb 2012 07:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_BACKHAIR_36=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xacfS2L+IFnO for ; Thu, 9 Feb 2012 07:34:31 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3B421F8606 for ; Thu, 9 Feb 2012 07:34:31 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 9E5351B405F for ; Thu, 9 Feb 2012 07:34:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=n/yHKGHB/NZfVtf6ijEXX r//0QAeZb3NAIzUfj9lf/gJrJ8cBatF0y1pZO0LQ8r/qPzYNAKF38S1nTGLhot1a I2haQZEsJLl2MnJV8zsF3HAvHSOSj4wqMulJkPh8U7H3rX40Egy/S+cxrluW8waw zRfFWnMlKWqifMpdryLGRg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=/tmMXql+0MYaBg6hvf8o EDL0MLQ=; b=pzZK6SqzTdJwfB9llQGoY5LpDAd5zz9meVzr4maCVghgKsSDThng mK0w6wPe0CPU2DVR4haF5yykgkS07eQ+Y61VOOQIX84/VDkzs5YHYkNxJ2YVegoP 3fiFp+wmOJhPllmsfrQe6PSyxcCID+sy6QCR/Uwn+megShLtRtIZ7iQ= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 82F881B4057 for ; Thu, 9 Feb 2012 07:34:30 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so1700839pbc.31 for ; Thu, 09 Feb 2012 07:34:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.217.67 with SMTP id ow3mr6719459pbc.125.1328801670124; Thu, 09 Feb 2012 07:34:30 -0800 (PST) Received: by 10.68.136.4 with HTTP; Thu, 9 Feb 2012 07:34:30 -0800 (PST) In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> Date: Thu, 9 Feb 2012 09:34:30 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: "therightkey@ietf.org" , Kyle Hamilton , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 15:34:35 -0000 On Thu, Feb 9, 2012 at 7:16 AM, Phillip Hallam-Baker wrote: > Agreed, but! No but, we agree on the rest regarding e-mail as well, and some of what you say is a restatement of what I said. You go further and note that the very fact that PGP and such public keys and capabilities are divorced from the MUAs is the problem -- something I hadn't noticed last night, but I agree. > Let us drop the end to end ideology in the dustbin and accept that > email is an MTA to MTA protocol, or to be more precise it is three > protocols: I'm happy to drop the end-to-end principle where it can't be applied. E-mail is mostly such a case (I say mostly because for a very, very small group of people PGP has worked well enough). > So now we see why security policy driven by MUA published security > policy is going to fail: there is no consistency in the MUA loop. I Indeed. There's no way to ensure that all your MUAs have the same capabilities. I regularly use four different MUAs myself. > read mail on four separate devices. They have no way to communicate > between themselves to negotiate a common security policy and I > certainly would not want them to. > > Conclusion: > > 1) Security policy is a property of MTAs and not MUAs and hence of > domains and not accounts. > > 2) We need a security policy layer for the internet as a whole and not > just for what people imagine to be the 'Web' or 'email' portions > thereof. This is a problem caused by stovepipe thinking and > non-my-problemism. Perhaps you're not communicating your vision of (2) very well. I'm not entirely sure what you mean, and I'm dubious of any one-size-fits-the-Internet scheme (if that's what you have in mind). > [...] > Add the capability for MTAs to publish policy and we can establish a > hop-by hop security mechanism that covers each of the three mail > interactions in three separate end-to-end sessions. Right. This is a case where hop-by-hop security is the best we can do. > Getting back to the bigger problem, no this is not solving all the > problems we are seeing in the Web space. But it is solving a pretty > big one there. Web security is harder to improve than email security > because we already have quite a bit of Web security and very little > email security. I agree with this as well. The web also has lots of end-to-end-ness, though HTTP doesn't require it, and, indeed, encourages middle boxes. And we also use the web for different purposes than e-mail. I don't think the hop-by-hop security argument applies quite as well to the web... For the web we really want end-to-end security (with the server's concentrator being thought of as part of the server). I'm open to arguments to the contrary. Perhaps you'd suggest hop-by-hop security where the hops are client<->ISP<->server? Nico -- From hallam@gmail.com Thu Feb 9 07:49:32 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BBA21F86B7 for ; Thu, 9 Feb 2012 07:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.864 X-Spam-Level: X-Spam-Status: No, score=-2.864 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_BACKHAIR_36=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw9LJNxrDxFx for ; Thu, 9 Feb 2012 07:49:28 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D73E21F86B6 for ; Thu, 9 Feb 2012 07:49:28 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3017079obb.31 for ; Thu, 09 Feb 2012 07:49:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+FpejVq6rwXH2IjDQU4Hq6ktq1BuwXJnR6vNxUI7ERs=; b=dHN36KqNbpYOtuZ5368L62mOx7UZQX3yZl4WlyeEMkhUsLdv6Eh0vvZSEiJxQuvZ02 VlPunxSDg4d+xnZngyZey/3sIHdbnGV7ENjh8+QU1aLyQ9yNZ5mBsg1CaHq9R+GWXQRH vj40gSuAlAa8HWQHWZJlP0zPZulxbOqgPPkxw= MIME-Version: 1.0 Received: by 10.182.75.102 with SMTP id b6mr2576129obw.9.1328802567757; Thu, 09 Feb 2012 07:49:27 -0800 (PST) Received: by 10.182.75.138 with HTTP; Thu, 9 Feb 2012 07:49:27 -0800 (PST) In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> Date: Thu, 9 Feb 2012 10:49:27 -0500 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" , Kyle Hamilton , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 15:49:32 -0000 I agree on the problem of Web middleboxen being a problem. What I really dislike about the BlueCoat solution is that it is transparent. Which is of course why enterprises like them. They can just deploy and forget. The fact that the purpose of the box is to violate core assurances in the Web UI is irrelevant to them. They have a regulatory requirement and will pay someone to achieve that at the least personal effort to them. I think we need to address SSL middleboxen properly (and not in this forum, probably in TLS). Like prostitution, there are people who are going to do this somehow, better to allow for it and regulate it properly than have it happening in dark corners. The next logical step is to attack the client with some sort of applet that adds a bogus root into the certstore. First off, the whole point of the SEC regulations is that traders etc. should know that they are being watched. So they should not be using a regular client anyway. They should be using a client that regularly tells them that their connections are being intercepted. I would think this is also advisable from a liability, privacy and ethical point of view. Second, anyone who demands a cert that allows them to intercept any SSL session is being an idiot and putting themselves at great personal risk. There are people who are prepared to do a very great deal to get such a cert. I believe in separation of duties for my own personal protection. Having an authorized bypass mode would enable the browser providers to provide the appropriate (and really really intrusive) warnings to the user at regular intervals. This is how Ari Luotonen, Rob McCool and co originally conceived SSL intercept back when they did the Netscape proxy. On Thu, Feb 9, 2012 at 10:34 AM, Nico Williams wrot= e: > On Thu, Feb 9, 2012 at 7:16 AM, Phillip Hallam-Baker w= rote: >> Agreed, but! > > No but, we agree on the rest regarding e-mail as well, and some of > what you say is a restatement of what I said. =A0You go further and note > that the very fact that PGP and such public keys and capabilities are > divorced from the MUAs is the problem -- something I hadn't noticed > last night, but I agree. > >> Let us drop the end to end ideology in the dustbin and accept that >> email is an MTA to MTA protocol, or to be more precise it is three >> protocols: > > I'm happy to drop the end-to-end principle where it can't be applied. > E-mail is mostly such a case (I say mostly because for a very, very > small group of people PGP has worked well enough). > >> So now we see why security policy driven by MUA published security >> policy is going to fail: there is no consistency in the MUA loop. I > > Indeed. =A0There's no way to ensure that all your MUAs have the same > capabilities. =A0I regularly use four different MUAs myself. > >> read mail on four separate devices. They have no way to communicate >> between themselves to negotiate a common security policy and I >> certainly would not want them to. >> >> Conclusion: >> >> 1) Security policy is a property of MTAs and not MUAs and hence of >> domains and not accounts. >> >> 2) We need a security policy layer for the internet as a whole and not >> just for what people imagine to be the 'Web' or 'email' portions >> thereof. This is a problem caused by stovepipe thinking and >> non-my-problemism. > > Perhaps you're not communicating your vision of (2) very well. =A0I'm > not entirely sure what you mean, and I'm dubious of any > one-size-fits-the-Internet scheme (if that's what you have in mind). > >> [...] >> Add the capability for MTAs to publish policy and we can establish a >> hop-by hop security mechanism that covers each of the three mail >> interactions in three separate end-to-end sessions. > > Right. =A0This is a case where hop-by-hop security is the best we can do. > >> Getting back to the bigger problem, no this is not solving all the >> problems we are seeing in the Web space. But it is solving a pretty >> big one there. Web security is harder to improve than email security >> because we already have quite a bit of Web security and very little >> email security. > > I agree with this as well. > > The web also has lots of end-to-end-ness, though HTTP doesn't require > it, and, indeed, encourages middle boxes. =A0And we also use the web for > different purposes than e-mail. =A0I don't think the hop-by-hop security > argument applies quite as well to the web... =A0For the web we really > want end-to-end security (with the server's concentrator being thought > of as part of the server). =A0I'm open to arguments to the contrary. > Perhaps you'd suggest hop-by-hop security where the hops are > client<->ISP<->server? > > Nico > -- --=20 Website: http://hallambaker.com/ From nico@cryptonector.com Thu Feb 9 08:10:04 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0852121F862F for ; Thu, 9 Feb 2012 08:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsoVWmh+3QO4 for ; Thu, 9 Feb 2012 08:09:59 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 08C1421F8636 for ; Thu, 9 Feb 2012 08:09:54 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id C14CB94065 for ; Thu, 9 Feb 2012 08:09:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=sD5Ia8f+SKNKlKkpEiL1OMT2fNl4MGnzkO2Xz7uepm9X /jp05bo+/zZDeS8ZiyLb4PADYMid9HuI/nzUX0iwY7/p4VXlS8kQ2yMwXNZiXI9f xkO/SNPjiCjPCjATEf/ZAOmu3/vjrAjs0MYW9SAPEiRWQ1o7BnrSDBdZaPIPNtU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=dXWf7jXCdsRSbqH1g0d4Wt8Gcn0=; b=AbRIyFZgGrL aB7+Pj8BNlqJ813xTN/+0lS+NLPQSjdkDxCQ04iWjpgYqpj2t9XKxVbnzQ4Pfwr6 pZK6p0uONmZBZr/pZSt6fHuPSD8A9Nct25NL5dajspEn6fPNhiVo1zV0zAqWupNs mwpOMTgcI6JpHMCZLyF5LUjBj539sLkk= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id B15FC9400D for ; Thu, 9 Feb 2012 08:09:53 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so1729164pbc.31 for ; Thu, 09 Feb 2012 08:09:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.232.103 with SMTP id tn7mr7210390pbc.74.1328803793438; Thu, 09 Feb 2012 08:09:53 -0800 (PST) Received: by 10.68.136.4 with HTTP; Thu, 9 Feb 2012 08:09:53 -0800 (PST) In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> Date: Thu, 9 Feb 2012 10:09:53 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" , Kyle Hamilton , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 16:10:04 -0000 On Thu, Feb 9, 2012 at 9:49 AM, Phillip Hallam-Baker wro= te: > I agree on the problem of Web middleboxen being a problem. > > What I really dislike about the BlueCoat solution is that it is > transparent. Which is of course why enterprises like them. They can > just deploy and forget. The fact that the purpose of the box is to > violate core assurances in the Web UI is irrelevant to them. They have > a regulatory requirement and will pay someone to achieve that at the > least personal effort to them. There is a much better solution: block most outgoing HTTPS. I know it works because I know of at least one major organization where such a policy is applied. There's also a prohibition on accessing sites for personal purposes. So no gmail, no nothing. There's also a prohibition on using personal systems (laptops, say) on the corporate network. How do people get by? Smartphones and wireless. Who needs to access the 'Net through an employer's network anymore? (Yes, I know, lots of people have no other way, but it's only a matter of time till very few have no other way.) > I think we need to address SSL middleboxen properly (and not in this > forum, probably in TLS). Like prostitution, there are people who are > going to do this somehow, better to allow for =C2=A0it and regulate it > properly than have it happening in dark corners. The next logical step > is to attack the client with some sort of applet that adds a bogus > root into the certstore. Web authentication that handles channel binding would detect the MITMs. Then authentication just fails. We could make it so users could choose to do hop-by-hop security across MITMs they approve of, but I'd rather just fail and let the user find a non-MITMed path. Sadly, *very* sadly, we don't have such authentication mechanisms on the web :( > First off, the whole point of the SEC regulations is that traders etc. > should know that they are being watched. So they should not be using a > regular client anyway. They should be using a client that regularly > tells them that their connections are being intercepted. I would think > this is also advisable from a liability, privacy and ethical point of > view. Indeed. Nico -- From nico@cryptonector.com Thu Feb 9 09:35:25 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF8B21F8766 for ; Thu, 9 Feb 2012 09:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.959 X-Spam-Level: X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTiB3Fa2qPXQ for ; Thu, 9 Feb 2012 09:35:25 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4621F8764 for ; Thu, 9 Feb 2012 09:35:25 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id D006910062 for ; Thu, 9 Feb 2012 09:35:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=pQIrHRkPLEhT3LP5de0TYdijJmg33W1xL20dbsWaBiPP DPl+bQ5H/MrdlBqu2Y7WALDaCgPAo1z/q8EVKyJiCM96XiF1wrKnIbc8wHv30Sra QHg6Oimo2V/Lj9/fClJ46CZIBcQRuj6LppLKdghIwn8h/QL9nPpLZ6jm/GPWxY0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=MxR9TsYUnpGg7oAsBuTCahYxdMc=; b=ebK2mFJFAkQ q8s8+bGVFrxx+R/GE5d0/RoohJOKbKiQOa8FfCeZ7wLxyh46Cu9qlvmNKGHsmXkw 42FmL2A9GfKp8vo9rtpw5E7Vj/gCC5FAk9x/rAwqACMNpHjispiqpljhtAPM4wGn 1ek+gSbBHz83A1caWRnL1nNUsYQ/jsuc= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id BE9061005D for ; Thu, 9 Feb 2012 09:35:24 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so1797807pbc.31 for ; Thu, 09 Feb 2012 09:35:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.240.164 with SMTP id wb4mr7878707pbc.57.1328808924465; Thu, 09 Feb 2012 09:35:24 -0800 (PST) Received: by 10.68.136.4 with HTTP; Thu, 9 Feb 2012 09:35:24 -0800 (PST) Date: Thu, 9 Feb 2012 11:35:24 -0600 Message-ID: From: Nico Williams To: therightkey@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [therightkey] As for MITMs, authentication with channel binding would defeat them X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 17:35:26 -0000 The only thing missing, of course, is web user authentication technologies that scale to the Internet and have channel binding support. I would like to see web userauth technologies that have support for channel binding. If such technologies were in widespread use then MITM CAs would be useless, therefore rare. Is it too late to work on this? The folks over at the ABFAB WG don't seem to think so, but I want more options than just Project Moonshot and Kerberos. Nico -- From kent@bbn.com Thu Feb 9 09:58:55 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF22921F85C3 for ; Thu, 9 Feb 2012 09:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.377 X-Spam-Level: X-Spam-Status: No, score=-106.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oAqN9h2nh5G for ; Thu, 9 Feb 2012 09:58:55 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 172C221F85C0 for ; Thu, 9 Feb 2012 09:58:54 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:41475 helo=[10.71.30.158]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvYGf-0007Ov-NW; Thu, 09 Feb 2012 12:58:54 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 9 Feb 2012 12:38:50 -0500 To: Bill Frantz From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 17:58:56 -0000 At 2:40 PM -0800 2/8/12, Bill Frantz wrote: >On 2/7/12 at 11:55, kent@bbn.com (Stephen Kent) wrote: > >>Keys are not really great identifiers; they change, > >Keys don't change. People or programs may wish to change the keys >they are using, but keys themselves are constant. Touche! You're right, but since people do change keys, and using an old key to represent a user would be confusing at best, I thought that I could get away with the shortcut statement. >>they are not human meaningful (and thus there has to be another >>layer of mapping between key and human-readable IDs, which creates >>more vulnerabilities), etc. > >It the key represents an authorization, it may not need to be human >meaningful. Authorization is managed by people; keys are not meaningful to people. So, to use keys to represent authorization, one has to add a layer of mapping, which creates more opportunities for errors. Hence, not a great idea. >We get a lot of comments wanting to achieve some level of assurance >about identification. For most uses, we are more interested in >authorization than in identification. (If we need identification for >auditing purposes, it can be included in the the authorization. For >example: > > Authorization to deposit to account 123456 as Joe User. I agree that authorization is the primary motivation for identification, but, since people manage authorization, we generally want to bind keys to IDs. When IDs are not central to authorization, certs with random names can be used, e.g., see RFCs 6480 & 6487. Steve From kent@bbn.com Thu Feb 9 09:59:32 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678C521E8028 for ; Thu, 9 Feb 2012 09:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.385 X-Spam-Level: X-Spam-Status: No, score=-106.385 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZA8Y77Gu1Tc8 for ; Thu, 9 Feb 2012 09:59:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 791A021E8021 for ; Thu, 9 Feb 2012 09:59:30 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:41475 helo=[10.71.30.158]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RvYHI-0007Ov-6K; Thu, 09 Feb 2012 12:59:29 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> Date: Thu, 9 Feb 2012 12:34:00 -0500 To: Phillip Hallam-Baker From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-883312128==_ma============" Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 17:59:32 -0000 --============_-883312128==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:22 PM -0500 2/8/12, Phillip Hallam-Baker wrote: >Alice has three mobile phones and six laptops. > >Using embedded keys in those devices for authorization is no problem >since each device can have a separate private key and the >authentication server tracks the fact that there are nine devices that >might authenticate Alice. > >The same model can even be made to work for confidentiality. Alice can >read her DRM protected Kindle content on any one of those devices. >(Though there may be limits on how many devices the DRM scheme will >permit). > > >Trying to make S/MIME email work in that scenario is futile. The >sender only tracks one private key for Alice. So Alice has to export >her private key to all her S/MIME clients. Not only is that terrible >security practice, it is too much work. Worse, Alice has to repeat the >process once a year. > >That is why I no longer believe that end-to-end is a desirable >quality. A security requirement that does not consider the cost it >imposes versus the risks it mitigates is ideology. OK, now I understand your argument (aided by 5 paragraphs explanatory of text). If this is the major issue, then, for the S/MIME context, one could develop procedures for easy, secure xfer of private keys between devices, so that Alice could have the same key for encryption (more properly decryption) for S/MINE. Procedures for doing this have been proposed in secruity conferences for at least a decade. Aslo, this is an issue only for encrypted S/MIME messages, not signed messages. Outside of enterprise contexts I rarely see encrypted messages, and I don't think the problem you cited is the primary' reason for this. Steve --============_-883312128==_ma============ Content-Type: text/html; charset="us-ascii" Re: [therightkey] Will the real RPF please stand up?
At 8:22 PM -0500 2/8/12, Phillip Hallam-Baker wrote:
Alice has three mobile phones and six laptops.

Using embedded keys in those devices for authorization is no problem
since each device can have a separate private key and the
authentication server tracks the fact that there are nine devices that
might authenticate Alice.

The same model can even be made to work for confidentiality. Alice can
read her DRM protected Kindle content on any one of those devices.
(Though there may be limits on how many devices the DRM scheme will
permit).


Trying to make S/MIME email work in that scenario is futile. The
sender only tracks one private key for Alice. So Alice has to export
her private key to all her S/MIME clients. Not only is that terrible
security practice, it is too much work. Worse, Alice has to repeat the
process once a year.

That is why I no longer believe that end-to-end is a desirable
quality. A security requirement that does not consider the cost it
imposes versus the risks it mitigates is ideology.

OK, now I understand your argument (aided by 5 paragraphs explanatory of text).

If this is the major issue, then, for the S/MIME context, one could
develop procedures for easy, secure xfer of private keys between devices, so that Alice could have the same key for encryption (more properly decryption)
for S/MINE. Procedures for doing this have been proposed in secruity conferences for at least a decade. Aslo, this is an issue only for encrypted S/MIME
messages, not signed messages. Outside of enterprise contexts I rarely see encrypted messages, and I don't think the problem you cited is the primary'
reason for this.

Steve

--============_-883312128==_ma============-- From ppatterson@carillon.ca Thu Feb 9 12:54:46 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D16421E8051 for ; Thu, 9 Feb 2012 12:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZIx0EKOVR3C for ; Thu, 9 Feb 2012 12:54:45 -0800 (PST) Received: from mail.carillon.ca (unknown [207.115.107.18]) by ietfa.amsl.com (Postfix) with ESMTP id 43E4921E8050 for ; Thu, 9 Feb 2012 12:54:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.carillon.ca (Postfix) with ESMTP id DE505A83DBF for ; Thu, 9 Feb 2012 15:56:25 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at rhea-new.carillon.ca Received: from mail.carillon.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHRy-QIWgBei for ; Thu, 9 Feb 2012 15:56:24 -0500 (EST) Received: from [192.168.6.188] (69-196-152-118.dsl.teksavvy.com [69.196.152.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.carillon.ca (Postfix) with ESMTPSA id 12515A83DCF for ; Thu, 9 Feb 2012 15:56:24 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: Patrick Patterson In-Reply-To: Date: Thu, 9 Feb 2012 15:54:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E0F5A48-E63D-47D6-BD9A-02D5FA1122BC@tid.es> To: therightkey@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [therightkey] Could we use a common plug in? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 20:54:46 -0000 Parts of what is being described sound a lot like the stuff we're = putting into PLASMA (although I think we're looking at different terms = for some of it). The issue will be in how to re-use the bits in PLASMA = and in REPUTE (which, I admit to not having looked at, but from this = exchange sounds like it may be a way to communicate/query the policies = that are used in PLASMA) and then figure out how to wedge that into more = general "communication" use cases like HTTP (bundling web pages into = PLASMA bundles and then doing all the complicated policy resolution = stuff prior to Grandma reading them isn't going to work :). Have fun. On 2012-01-28, at 11:10 AM, Phillip Hallam-Baker wrote: > That looks important and useful. >=20 > It is not clear if this is quite the same application, but certainly > close. At a minimum we want to be able to transport REPUTE assertions > over whatever protocol we develop. >=20 > I can't see a REST type protocol layered over HTTP being a viable > replacement for DNS client-recursive resolver. But whatever broker is > working is going to be wanting to pull REPUTE type data. >=20 >=20 > On Sat, Jan 28, 2012 at 8:34 AM, DIEGO LOPEZ GARCIA = wrote: >>=20 >> On 27 Jan 2012, at 18:29 , Phillip Hallam-Baker wrote: >>> My experience of DNS is that the first is a terrible idea. The DNS >>> protocol is already stretched and there is a huge amount of legacy. >>> The DNS protocol has to serve two separate purposes, first it is the >>> protocol for communicating between the name server and the local >>> server, second between the client and the local server. It is only = the >>> first of these protocols that would require tweakage. >>>=20 >>> Another reason for not using DNS protocol is that there is >>> (potentially) a different trust model. Only some of the security >>> policy statements are coming from the DNS. In Perspectives and >>> Convergence we have data that is essentially coming from a new = trusted >>> party as well. >>>=20 >>>=20 >>> Any new online service would have to support a UDP query mode with >>> some sort of lightweight security. It would have to support = transport >>> of a range of data and there would have to be some mechanism for >>> backing off to legacy DNS when the new protocol was not available. >>=20 >>=20 >> What you describe here sounds very much aligned to the discussions = inside the REPUTE WG on a lightweight reputation query protocol, for = which COAP looks like an attractive choice. >>=20 >> Be goode, >>=20 >> -- >> "Esta vez no fallaremos, Doctor Infierno" >>=20 >> Dr Diego R. Lopez >> Telefonica I+D >> http://people.tid.es/diego.lopez/ >>=20 >> e-mail: diego@tid.es >> Tel: +34 913 129 041 >> Mobile: +34 682 051 091 >> ----------------------------------------- >>=20 >>=20 >> Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico en el enlace situado m=E1s abajo. >> This message is intended exclusively for its addressee. We only send = and receive email on the basis of the terms set out at >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --- Patrick Patterson Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca From diego@tid.es Thu Feb 9 14:29:21 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB8A11E808F for ; Thu, 9 Feb 2012 14:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.276 X-Spam-Level: X-Spam-Status: No, score=-5.276 tagged_above=-999 required=5 tests=[AWL=1.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0Fs3YNtB4gK for ; Thu, 9 Feb 2012 14:29:20 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 13FC811E8073 for ; Thu, 9 Feb 2012 14:29:19 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ500H8YD4UGM@tid.hi.inet> for therightkey@ietf.org; Thu, 09 Feb 2012 23:29:18 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 9B.F1.02643.DB8443F4; Thu, 09 Feb 2012 23:29:18 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LZ500H8TD4TGM@tid.hi.inet> for therightkey@ietf.org; Thu, 09 Feb 2012 23:29:17 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Thu, 09 Feb 2012 23:29:17 +0100 Date: Thu, 09 Feb 2012 23:29:16 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: Stephen Kent Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [therightkey] Will the real RPF please stand up? Thread-index: AcznekIIT2oZd0YHRUqjW7I/X/y+EQ== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-71-4f3448bdc737 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsXCFe9nqLvPw8Tf4O4rDouPF36yODB6LFny kymAMYrLJiU1J7MstUjfLoEr43/zTLaCTbwVV15sYG5gvMHVxcjJISFgIvH50hpmCFtM4sK9 9WxdjFwcQgLbGCVmXoVx/jFKbLt/lgnCaWSUuPH7FStIC4uAqsTZadfB2tkE1CVajn5jAbGF BWwlXu/5BFbDCbTid9tCsLiIgLzEt2NbwWxmgWiJSdNugPXyClhKrNg7lxXCFpT4MfkeVI2e xMc/txkhbHGJ5tabUHFtiSfvLoDVMwKd/f3UGiaI+XYSkx+8YYOw9ST+9fxlgagRlbjTvp4R 4k0BiSV7zkO9LCrx8vE/VojHJjNJrL9/hX0Co/gsJHfMQnLHLCR3zEJyxwJGllWMYsVJRZnp GSW5iZk56QZGehmZepl5qSWbGCGxlLmDcflOlUOMAhyMSjy8HFIm/kKsiWXFlbmHGCU5mJRE eSc7A4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8FrzAeV4UxIrq1KL8mFSMhwcShK8F92BUoJF qempFWmZOcCEAZNm4uAEaecBaj8JUsNbXJCYW5yZDpE/xSgpJc77HCQhAJLIKM2D633FKA50 pDDvaZAsDzC1wXW9AhrIBDQwhckQZGBJIkJKqoFR1UbTuSzp9OojVdknr3/hK3A573Ct9P6u eR828u9kCsjSupp/R+jP22pVoTvsJz/ZlVjnal1aqVx8mOFhZfvNx4WPZA6utfq4/Y/cq8ly zPm37Y5Oqnnd78yt0iG/qeT1f+b2CN6pbafXLXO9KCe+/VCt5M1OPreS89LbLkzY7/ucW/YQ d0mREktxRqKhFnNRcSIApt7HPyoDAAA= References: <12020712051780_4AE3A@oregon.uoregon.edu> <10ED67C0-F0ED-4D2C-B897-0BE97689EDF5@tid.es> Cc: Joe St Sauver , "therightkey@ietf.org" Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 22:29:21 -0000 On 8 Feb 2012, at 20:30 , Stephen Kent wrote: > I think the real issue, which you ay have overlooked in my comments > above, is the notion that the best candidate for a CA is an entity > that is authoritative for the identity asserted in the cert. I cannot agree more with you in that statement. And I don't think I overloo= ked it. What made me reply was the point about federated identity ("having = one org trust another to assert and identity for a user known to the second= , but not the first") being "a recipe for security problems". My point was = that a certificate was precisely such an assertion, and I do agree with you= in that whichever entity making such assertion (X.509, SAML, JWT=85) has t= o be authoritative for the identity asserted if you want it to be usable. > Based on you reply, I get the sense that you're focusing on CAs like the > current set of browser TAs, all of which fail to meet the criteria I > cited. As well as many of the federation systems you and I are aware of, for sure.= But not all, and not because the concept behind them is flawed. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx From aerowolf@gmail.com Thu Feb 9 14:46:32 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60ACD21E805E for ; Thu, 9 Feb 2012 14:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.491 X-Spam-Level: X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CD2bJtx5skr0 for ; Thu, 9 Feb 2012 14:46:32 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB5D721E8044 for ; Thu, 9 Feb 2012 14:46:31 -0800 (PST) Received: by iagf6 with SMTP id f6so3844098iag.31 for ; Thu, 09 Feb 2012 14:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=e7tZLD5eWXv1neIW6OObimn8HSWs4Dg56jks8xH/u2A=; b=gKuj+5TIA1KUN5WLHsdu8gk1hj2D97ktxl7AeemVgI72usLPGVNINgD0y3uftIv2uc hPD3I09SwWPKs8AT/jOC5UD35HxJAz/UERnDAXjbh0/Nr4TUCaPuH+cXVZwz15hwtX5j /fUFkwso6IcAMyDewV23sLZKZTxxeWaPtjtfs= Received: by 10.50.155.231 with SMTP id vz7mr5479109igb.26.1328827591507; Thu, 09 Feb 2012 14:46:31 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id d15sm7715299ibf.7.2012.02.09.14.46.28 (version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 14:46:29 -0800 (PST) From: "Kyle Hamilton" To: "Phillip Hallam-Baker" Date: Thu, 9 Feb 2012 14:46:31 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgygdmzv0hpexhvde872 Cc: Nico Williams , "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 22:46:32 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgygdmzv0hpexhvde872 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 DQoNCk9uIFRodSwgRmViIDksIDIwMTIgYXQgNzo0OSBBTSwgUGhpbGxpcCBIYWxsYW0tQmFrZXIg PGhhbGxhbUBnbWFpbC5jb20+IHdyb3RlOg0KPiBJIGFncmVlIG9uIHRoZSBwcm9ibGVtIG9mIFdl YiBtaWRkbGVib3hlbiBiZWluZyBhIHByb2JsZW0uDQo+DQo+IFdoYXQgSSByZWFsbHkgZGlzbGlr ZSBhYm91dCB0aGUgQmx1ZUNvYXQgc29sdXRpb24gaXMgdGhhdCBpdCBpcw0KPiB0cmFuc3BhcmVu dC4gV2hpY2ggaXMgb2YgY291cnNlIHdoeSBlbnRlcnByaXNlcyBsaWtlIHRoZW0uIFRoZXkgY2Fu DQo+IGp1c3QgZGVwbG95IGFuZCBmb3JnZXQuIFRoZSBmYWN0IHRoYXQgdGhlIHB1cnBvc2Ugb2Yg dGhlIGJveCBpcyB0bw0KPiB2aW9sYXRlIGNvcmUgYXNzdXJhbmNlcyBpbiB0aGUgV2ViIFVJIGlz IGlycmVsZXZhbnQgdG8gdGhlbS4gVGhleSBoYXZlDQo+IGEgcmVndWxhdG9yeSByZXF1aXJlbWVu dCBhbmQgd2lsbCBwYXkgc29tZW9uZSB0byBhY2hpZXZlIHRoYXQgYXQgdGhlDQo+IGxlYXN0IHBl cnNvbmFsIGVmZm9ydCB0byB0aGVtLg0KDQpJIHRoaW5rIHRoaXMgY2FuIGJlIHNvbHZlZCB2aWEg Y29kZS4gIE1ha2UgaXQgc28gdGhhdCBuYW1lOmNlcnRpZmljYXRlIHBhaXJzIHdoaWNoIHBhc3Mg YmFzZWQgb24gdGhlIGJ1aWx0LWluIHJvb3RzIGNhbiBwcmVzZW50IGJsdWUgYW5kIGdyZWVuLCBh bmQgY2VydGlmaWNhdGVzIHdoaWNoIHBhc3MgYmFzZWQgb24gbm9uLWJ1aWx0LWluIHJvb3RzIHNo b3cgdXAgaW4gZ29sZC4NCg0KPiBJIHRoaW5rIHdlIG5lZWQgdG8gYWRkcmVzcyBTU0wgbWlkZGxl Ym94ZW4gcHJvcGVybHkgKGFuZCBub3QgaW4gdGhpcw0KPiBmb3J1bSwgcHJvYmFibHkgaW4gVExT KS4gTGlrZSBwcm9zdGl0dXRpb24sIHRoZXJlIGFyZSBwZW9wbGUgd2hvIGFyZQ0KPiBnb2luZyB0 byBkbyB0aGlzIHNvbWVob3csIGJldHRlciB0byBhbGxvdyBmb3IgoGl0IGFuZCByZWd1bGF0ZSBp dA0KPiBwcm9wZXJseSB0aGFuIGhhdmUgaXQgaGFwcGVuaW5nIGluIGRhcmsgY29ybmVycy4gVGhl IG5leHQgbG9naWNhbCBzdGVwDQo+IGlzIHRvIGF0dGFjayB0aGUgY2xpZW50IHdpdGggc29tZSBz b3J0IG9mIGFwcGxldCB0aGF0IGFkZHMgYSBib2d1cw0KPiByb290IGludG8gdGhlIGNlcnRzdG9y ZS4NCg0KVGhlIG5leHQgbG9naWNhbCB3YXkgdG8gZGVmZW5kIGFnYWluc3QgdGhpcyBpcyB0byBl bmFibGUgaXQgb24gb3VyIHRlcm1zLg0KDQo+IEhhdmluZyBhbiBhdXRob3JpemVkIGJ5cGFzcyBt b2RlIHdvdWxkIGVuYWJsZSB0aGUgYnJvd3NlciBwcm92aWRlcnMgdG8NCj4gcHJvdmlkZSB0aGUg YXBwcm9wcmlhdGUgKGFuZCByZWFsbHkgcmVhbGx5IGludHJ1c2l2ZSkgd2FybmluZ3MgdG8gdGhl DQo+IHVzZXIgYXQgcmVndWxhciBpbnRlcnZhbHMuIFRoaXMgaXMgaG93IEFyaSBMdW90b25lbiwg Um9iIE1jQ29vbCBhbmQgY28NCj4gb3JpZ2luYWxseSBjb25jZWl2ZWQgU1NMIGludGVyY2VwdCBi YWNrIHdoZW4gdGhleSBkaWQgdGhlIE5ldHNjYXBlDQo+IHByb3h5Lg0KDQpXaHkgaXNuJ3QgdGhp cyBhbHJlYWR5IHBhcnQgb2YgdGhlIGJyb3dzZXIgY29kZXMgd2hpY2ggaGFuZGxlIG5ldHdvcmsg cHJveGllcz8NCg0KLUt5bGUgSA== --gmsm1.9.5eqgygdmzv0hpexhvde872 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMDkyMjQ2MzFaMCMGCSqGSIb3DQEJBDEWBBSG6kgsxo80PK6C+MLoG3Xt JdwJqjBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEABRJzenlBGX1Fx0HUZ+btr8fL2t2J1nz+gbbTy87d5dl1JDw/9oVLfoAnmnvYJQTDzuqn AofDKE1O+eRIDT/9gh8W7+iFns8QE3tOKNC5aK2foiJ4jIn9s4WrHb9cxAXMy5iRZvh1I2bg0f8D A8b/axacNQFoBynUnB4HtERpxE/8VOTDbmu1UFY3d5aq+XrXoDr1R2fipu/xtGqOOcm4fanqM45K +9rgkeBjzGz8TYJehMSjmZmqrkfqq6535YQkbTnkpMHQUrWORib6XLdJKVlVhikvGk1WoCxB8/Jt P7gz9e8fAl55Sd60skLHF9CQf3Mve1CHfd86QtE8uKhwlAAAAAAAAA== --gmsm1.9.5eqgygdmzv0hpexhvde872-- From ynir@checkpoint.com Thu Feb 9 15:04:11 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB8811E808F; Thu, 9 Feb 2012 15:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0tPYME8DKdg; Thu, 9 Feb 2012 15:04:11 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 038E511E808A; Thu, 9 Feb 2012 15:04:10 -0800 (PST) X-CheckPoint: {4F344D42-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q19N458e026029; Fri, 10 Feb 2012 01:04:05 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 10 Feb 2012 01:04:05 +0200 From: Yoav Nir To: Nico Williams Date: Fri, 10 Feb 2012 01:04:10 +0200 Thread-Topic: [therightkey] As for MITMs, authentication with channel binding would defeat them Thread-Index: Acznfx53GOxIb8r1TGebDXOj3Duuog== Message-ID: <754D9EA1-2418-4438-ABAB-B5F7241AD0A2@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" , "http-auth@ietf.org" Subject: Re: [therightkey] As for MITMs, authentication with channel binding would defeat them X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 23:04:12 -0000 On Feb 9, 2012, at 7:35 PM, Nico Williams wrote: > The only thing missing, of course, is web user authentication > technologies that scale to the Internet and have channel binding > support. >=20 > I would like to see web userauth technologies that have support for > channel binding. >=20 > If such technologies were in widespread use then MITM CAs would be > useless, therefore rare. >=20 > Is it too late to work on this? The folks over at the ABFAB WG don't > seem to think so, but I want more options than just Project Moonshot > and Kerberos. This thread looks to me like it's more appropriate for the http-auth mailin= g list. The "charter" of therightkey is pretty specific in that it talks ab= out PKI authentication only. This will be a one-time-only cross-post. Yoav= From kent@bbn.com Thu Feb 9 15:06:30 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3687E11E8096 for ; Thu, 9 Feb 2012 15:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.394 X-Spam-Level: X-Spam-Status: No, score=-106.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQcWqvRFT0qp for ; Thu, 9 Feb 2012 15:06:29 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6E63F11E808A for ; Thu, 9 Feb 2012 15:06:29 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:58802 helo=[10.71.30.158]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rvd4I-000DM2-PE; Thu, 09 Feb 2012 18:06:23 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <10ED67C0-F0ED-4D2C-B897-0BE97689EDF5@tid.es> Date: Thu, 9 Feb 2012 18:05:47 -0500 To: DIEGO LOPEZ GARCIA From: Stephen Kent Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: Joe St Sauver , "therightkey@ietf.org" Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 23:06:30 -0000 At 11:29 PM +0100 2/9/12, DIEGO LOPEZ GARCIA wrote: >On 8 Feb 2012, at 20:30 , Stephen Kent wrote: > >...and I do agree with you in that whichever=20 >entity making such assertion (X.509, SAML, JWT=8A)=20 >has to be authoritative for the identity=20 >asserted if you want it to be usable. I think we are in agreement. CAs that are not authoritative for asserted identities are as bad as federated trust entities with similar properties. Steve From nico@cryptonector.com Thu Feb 9 15:14:49 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6ADF21F85BD for ; Thu, 9 Feb 2012 15:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 732A7w-TrIhg for ; Thu, 9 Feb 2012 15:14:49 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 370F521F85AE for ; Thu, 9 Feb 2012 15:14:49 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id F13B820203C for ; Thu, 9 Feb 2012 15:14:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=YJ7F9OQcR2Y5dTYLxF5TY SSDZUTyHCMsQrTP5TEUnqSfirYe6YWL4v4UVUFwkgzO7ATG1bXtduQ4a+HHAd6OE GDGwMiR8iY35opCtbM5HATqg3P2dRIClFFMHB7fGCys3LiT7f3Lx1jlOawRrQQFd lJEqEN62ldycKmk+3nj3as= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=kydYl4mcMZ5Ix3Q3ax6x uQmibUU=; b=O97+9CzcRF2ZxzysT82fYAsWYCvOUSu959sqWAQ5VOKMeZQyXCB5 EtpqJk5izrk+ieDHFB/1uRnZf4nuZdR+lbzpBAXw3GhffyO7bqdRcY0XvfKx9RkN 0yKx/1AI8q0byioRgVfP0cVHAAsPOxpCQMizLFv2Zujl7n15gAAF7rU= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id C6D5B20202C for ; Thu, 9 Feb 2012 15:14:48 -0800 (PST) Received: by dakl33 with SMTP id l33so1959748dak.31 for ; Thu, 09 Feb 2012 15:14:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.135.137 with SMTP id ps9mr10426645pbb.40.1328829288238; Thu, 09 Feb 2012 15:14:48 -0800 (PST) Received: by 10.68.136.4 with HTTP; Thu, 9 Feb 2012 15:14:48 -0800 (PST) In-Reply-To: <754D9EA1-2418-4438-ABAB-B5F7241AD0A2@checkpoint.com> References: <754D9EA1-2418-4438-ABAB-B5F7241AD0A2@checkpoint.com> Date: Thu, 9 Feb 2012 17:14:48 -0600 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] As for MITMs, authentication with channel binding would defeat them X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 23:14:49 -0000 The relevance to PKI is that those MITM CAs wouldn't be such a big deal if they were useless. If anyone wants to continue down the "how to get CB deployed" I agree we should continue on the http auth list. From joe@oregon.uoregon.edu Thu Feb 9 15:31:51 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F33621E803B for ; Thu, 9 Feb 2012 15:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eC+Z2lqBUew for ; Thu, 9 Feb 2012 15:31:50 -0800 (PST) Received: from grey.uoregon.edu (grey.uoregon.edu [128.223.214.89]) by ietfa.amsl.com (Postfix) with SMTP id C233721E805E for ; Thu, 9 Feb 2012 15:31:49 -0800 (PST) Date: Thu, 9 Feb 2012 15:14:35 -0800 (PST) Message-Id: <12020915143552_4D9A6@oregon.uoregon.edu> From: "Joe St Sauver" To: kent@bbn.com X-VMS-To: SMTP%"kent@bbn.com" X-VMS-Cc: SMTP%"therightkey@ietf.org" Cc: therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 23:31:51 -0000 Steve commented: #I think we are in agreement. CAs that are not authoritative for asserted #identities are as bad as federated trust entities with similar properties. I tend to be a concrete thinker, so I hope you'll indulge me for a minute in a concrete exercise related to your assertion. -- Assume a hypothetical CA is operated by a national government, and it issues client certs to citizens of that nation. I belive that this would like be an example of a CA that is authoritative for the identities that it is asserting -- true? (We'll set aside issues of how governments bootrap a definitive identification document in the potential absence of an existing definitive identification document) -- Would a hypothetical CA operated by a corporation, issuing client certs to its employees, also be authoritative for its employees from your point of view? Does it matter if they assert a name or a company email address or ? (We'll set aside the possibility that credentials might be able to be issued by the corporation without the involvement of the employee nominally associated with that credential) -- What's the solution for the person who lacks a authoritative source for a certificate? Would it be better if they simply couldn't get a cert? Or is there some road that they might travel that might allow them to find (like Dorothy and the Wizard of Oz), someone who could become authoritative for them? -- What if the authoritative source is unwilling to issue credentials to one of its subjects/employees/members? (e.g., think of some individuals who have been denied the right to travel in some countries in the past) Should there be the certificate equivalent of a Nansen passport for those who are effectively stateless? Or should we just be trusting a certification authority to do what it says it will do in its CPS, perhaps just confirming that an email address asserted in a certificate request is indeed accessible by the party that's requesting a cert with that "identity"? Thanks, Joe From kent@bbn.com Thu Feb 9 16:23:30 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA6711E808F for ; Thu, 9 Feb 2012 16:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.401 X-Spam-Level: X-Spam-Status: No, score=-106.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd6uvWP9fC0l for ; Thu, 9 Feb 2012 16:23:29 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6C88111E8079 for ; Thu, 9 Feb 2012 16:23:29 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:40134 helo=[10.71.30.158]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RveGu-000Dzu-13; Thu, 09 Feb 2012 19:23:28 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <12020915143552_4D9A6@oregon.uoregon.edu> References: <12020915143552_4D9A6@oregon.uoregon.edu> Date: Thu, 9 Feb 2012 19:22:41 -0500 To: "Joe St Sauver" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: therightkey@ietf.org Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 00:23:30 -0000 At 3:14 PM -0800 2/9/12, Joe St Sauver wrote: >Steve commented: > >#I think we are in agreement. CAs that are not authoritative for asserted >#identities are as bad as federated trust entities with similar properties. > >I tend to be a concrete thinker, so I hope you'll indulge me for a minute >in a concrete exercise related to your assertion. no problem. >-- Assume a hypothetical CA is operated by a national government, and it > issues client certs to citizens of that nation. I belive that this would > like be an example of a CA that is authoritative for the identities that > it is asserting -- true? (We'll set aside issues of how governments > bootrap a definitive identification document in the potential absence > of an existing definitive identification document) yes, this is a good example, if the certs convey the identity of the individuals as citizens of that country. >-- Would a hypothetical CA operated by a corporation, issuing client certs > to its employees, also be authoritative for its employees from your > point of view? Does it matter if they assert a name or a company email > address or ? (We'll set aside the possibility that credentials might > be able to be issued by the corporation without the involvement of the > employee nominally associated with that credential) A CA operated by a company is the right CA to identity individuals as employees of that company. if the company operates it's domain and manages mailboxes for its employees in that domain, then it is he right CA to issue certs with employee e-mail addresses. >-- What's the solution for the person who lacks a authoritative source > for a certificate? Would it be better if they simply couldn't get a > cert? Or is there some road that they might travel that might allow > them to find (like Dorothy and the Wizard of Oz), someone who could > become authoritative for them? Note that the citizen and employee certs are not universally acceptable for all transactions. The citizen cert is analogous to a passport, and I can't use a passport in lieu of a driver's license or an Amex card. We need different certs to express different forms of identity. So, I think the right question is what classes of certs do people need, for which classes of transactions. If I can get a driver's license or state-issued ID card, then I ought be be able to get the same credential in cert format. So, If a person has no e-mail address, he ought not get a cert with an email address in it. If you have a Gmail address, then Google is the right entity to issue a cert with ONLY an e-mail address in it. Given this explanation, I don't understand you question. it sounds like you are thinking of a one cert per person model, which is the antithesis of what I suggested. >-- What if the authoritative source is unwilling to issue credentials to > one of its subjects/employees/members? (e.g., think of some individuals > who have been denied the right to travel in some countries in the past) > Should there be the certificate equivalent of a Nansen passport for > those who are effectively stateless? Depends. If a company will not issue certs to its employees, then they can't be reliably certified as employees of the company in question. Nansen passports are not issued anymore, but the moral equivalent is issued by the UN today. Such a cert would not identity the holder as a citizen of a specific country, which is the feature of a passport. >Or should we just be trusting a certification authority to do what it >says it will do in its CPS, perhaps just confirming that an email address >asserted in a certificate request is indeed accessible by the party that's >requesting a cert with that "identity"? Trusting a CA based on its CPS, without an ability to constrain the scope of identities that the CA can certify is dangerous. This is why we have the current mess of Steve From aerowolf@gmail.com Thu Feb 9 23:02:45 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B4421F84EE for ; Thu, 9 Feb 2012 23:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy6wp7FhJNPG for ; Thu, 9 Feb 2012 23:02:44 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92DD821F84EC for ; Thu, 9 Feb 2012 23:02:44 -0800 (PST) Received: by iagf6 with SMTP id f6so4548787iag.31 for ; Thu, 09 Feb 2012 23:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:mime-version:content-type; bh=aieJAQsFT8+It+Sz19DI01ougY+emew4Ke5zyc/AO80=; b=wQ+Ip9vbUeWjvKRWZxAem4DxDAtC5Fyl7S1p5RZORU3jikBizhxYWoIgS8l0roBx5f frInb/RRFma0qd3N7TvQiZCK35KAXBW4MLmftDA064Z0Oe1je3NK/i1KjR7kOpVCl8iB GNQqPCyXp0MQw0b36W/aAtXsfjFwQHT4f308U= Received: by 10.50.10.225 with SMTP id l1mr8524920igb.9.1328857364196; Thu, 09 Feb 2012 23:02:44 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id ak10sm8150057igc.6.2012.02.09.23.02.41 (version=SSLv3 cipher=OTHER); Thu, 09 Feb 2012 23:02:42 -0800 (PST) From: "Kyle Hamilton" To: "Stephen Kent" Date: Thu, 9 Feb 2012 23:02:42 -0800 (Pacific Standard Time) Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgygvd2uu3ek8g84lzj2 Cc: therightkey@ietf.org, Phillip Hallam-Baker Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 07:02:45 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgygvd2uu3ek8g84lzj2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 DQoNCk9uIFdlZCwgRmViIDgsIDIwMTIgYXQgOTowNiBBTSwgU3RlcGhlbiBLZW50IDxrZW50QGJi bi5jb20+IHdyb3RlOg0KPiBTbywgSSBkb24ndCBhZ3JlZSB0aGF0IHRoZSBkaXN0aW5jdGlvbiBi ZXR3ZWVuIHRoZSB1c2VyIGFuZCBhIG1hY2hpbmUNCj4gb3BlcmF0ZWQgYnkgYSB1c2VyIGlzIHJl YWxseSBzaWduaWZpY2FudCwgaW4gdGhlIGVuZC4goChZZXMsIEkgYW0gd2FyZSBvZg0KPiB0aGUg bWFueSBzZWN1cml0eSBwcm9ibGVtcyB0aGF0IGFyaXNlIGJlY2F1c2UgdGhlIHVzZXIgZG9lc24n dCByZWFsbHkga25vdw0KPiB3aGF0IHRoZSBjb2RlIGlzIGRvaW5nLCBidXQgbm90aGluZyBpcyBw ZXJmZWN0LikNCg0KSSBiZWxpZXZlIHRoYXQgdGhlcmUncyBhIHZlcnkgZ29vZCByZWFzb24gdG8g c2VwYXJhdGUgdGhlbS4gIFdlJ3JlIGdvaW5nIHRvIG5lZWQgdG8gbW92ZSB0byBhIHN5c3RlbSB3 aGVyZSB3ZSBoYXZlIGVmZmVjdGl2ZWx5IGEgc2VwYXJhdGUgVUlEIHBlciBhcHBsaWNhdGlvbiwg d2l0aGluIHRoZSBvdmVyYXJjaGluZyB1c2VyJ3MgVUlELiAgVGhpcyBpcyB0aGUgb25seSBlZmZl Y3RpdmUgd2F5IHRvIGlzb2xhdGUgdGhlIGRhbWFnZSB3aGljaCBvbmUgYXBwbGljYXRpb24gY2Fu IGNhdXNlLCBhbmQgdGhlIG9ubHkgZWZmZWN0aXZlIHdheSB0byBhdWRpdCBwcmVjaXNlbHkgd2hp Y2ggYXBwbGljYXRpb24gZGlkIHdoYXQgZGFtYWdlLg0KDQpUaGlzIGlzIGEgcmVjYXN0aW5nIG9m IEFuZHJvaWQncyBtb2RlbCwgd2hlcmUgdGhlICJ1c2VyIElEIiBpcyAidGhlIGRldmljZSdzIGNv bnRyb2xsZXIiLCBhbmQgdGhlIGFwcGxpY2F0aW9ucyB0aGVtc2VsdmVzIGFyZSBhc3NpZ25lZCBM aW51eCBVSURzIHNvIHRoZXkgY2FuJ3QgaW50ZXJmZXJlIHdpdGggZWFjaCBvdGhlci4NCg0KPiBJ IGFncmVlIHRoYXQgY3JlZGVudGlhbCBwb3J0YWJpbGl0eSBpcyBlc3NlbnRpYWwuIFsuLi5dDQoN CkNyZWRlbnRpYWwgcG9ydGFiaWxpdHkgaXMgb3ZlcnJhdGVkLiAgVGhlIHJlYWwgcHJvYmxlbSBp cyBjcmVkZW50aWFsIGVxdWl2YWxlbmNlLg0KDQo+PiBTL01JTUUgd2l0aCBhIHByaXZhdGUga2V5 IHNoYXJlZCB0byBmaWZ0ZWVuIGRldmljZXMgbm8gbG9uZ2VyIGxvb2tzDQo+PiB2ZXJ5IHNlY3Vy ZSB0byBtZS4NCg0KUy9NSU1FIHdpdGggYSBwcml2YXRlIGtleSBzdG9yZWQgb24gYSBkYWVtb24g c3lzdGVtIGFuZCB1bmlxdWUgcHJpdmF0ZSBrZXlzIG9uIGVhY2ggb2YgZm91cnRlZW4gYWNjZXNz aW5nIGNsaWVudHMsIG9uIHRoZSBvdGhlciBoYW5kLi4uDQoNCj4gQ3JlZG5ldGlhbCBwb3J0YWJp bGl0eSBkb2VzIG5vdCBuZWNlc3NhcmlseSBpbXBseSBhIHByaXZhdGUga2V5IGtlcHQgaW4gU1cN Cj4gaW4goGV2ZXJ5IGRldmljZS4NCg0KQ3JlZGVudGlhbCBwb3J0YWJpbGl0eSBkb2VzLCBob3dl dmVyLCBpbXBseSBhIHByaXZhdGUga2V5IG9yIG90aGVyIGF1dGhlbnRpY2F0b3IgbXVzdCBiZSBo YW5kbGVkIGluIFNXIGluIGV2ZXJ5IGRldmljZS4gIEludGVybWl0dGVudCBzZWN1cml0eSBpcyBo YXJkZXIgdGhhbiBjb21wbGV0ZSBzZWN1cml0eSBpbiBhIHN1ZmZpY2llbnRseSBjb21wbGV4IHN5 c3RlbS4NCg0KLUt5bGUgSA0K --gmsm1.9.5eqgygvd2uu3ek8g84lzj2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTAwNzAyNDJaMCMGCSqGSIb3DQEJBDEWBBSH3bp2btCzxv0ttT6DrcBh hoVsMDBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAITwXPjDQDYQOsj/JwYJz+37pWEQbZqWuj9KAbGKercC997lbVoOrn8Eq+CR2OB90BpUY u216qfw9Ufzt3zLHXvWaeF+Db1Sm5YFoepY65pcIJ1gXeL8MClg+htI9FQgKywifp4xpEKHVpJcY 1TwLi5PR8XnlsVimB3S53RR5SLcMgDXX0qV3iKtAPvy75QjQ9Ea0YUJ3PDtW1fOLyK2iTJ3DPvPV jVf8PALqoy+Fqnt1/P86GpmnDjIZOb9iotLwe5ZUK9bR6/e70G53g2S2ffUKD+sJvacZmJHYsK+d 1wV69SXLbLVEGH2qrn6I76J5DPa2/I79naYNAffpWEncYgAAAAAAAA== --gmsm1.9.5eqgygvd2uu3ek8g84lzj2-- From diego@tid.es Thu Feb 9 23:48:27 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FB721F8559 for ; Thu, 9 Feb 2012 23:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.346 X-Spam-Level: X-Spam-Status: No, score=-5.346 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JsTHYYDTrh6 for ; Thu, 9 Feb 2012 23:48:26 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8A98B21F8554 for ; Thu, 9 Feb 2012 23:48:26 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZ6005VA30M2Y@tid.hi.inet> for therightkey@ietf.org; Fri, 10 Feb 2012 08:48:25 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id C8.D3.02643.8CBC43F4; Fri, 10 Feb 2012 08:48:25 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LZ6005VF30O2Y@tid.hi.inet> for therightkey@ietf.org; Fri, 10 Feb 2012 08:48:24 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Fri, 10 Feb 2012 08:48:24 +0100 Date: Fri, 10 Feb 2012 08:48:23 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: Stephen Kent Message-id: <3DC7B7BB-1685-4672-B1EC-CBAA121A1ACE@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [therightkey] Will the real RPF please stand up? Thread-index: AcznyF25JTAwqdnvQEGfeshaBsDivw== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f6b6d000000a53-1b-4f34cbc895be X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsXCFe9nqHvytIm/wdrl7BYfL/xkcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoGGVewFl3grNr7cy9LAuIS3i5GTQ0LAROLB85nMELaYxIV7 69m6GLk4hAS2MUrcOLSEFcL5xygx99tTRginkVHiU8dVoBYODhYBVYnr6+NAutkE1CVajn5j AbGFBWwlXu/5xApicwoYS3zb3gW2QURAXuLbsa1gNcwC0RKTpt0Ai/MKWEpcOXWcFcIWlPgx +R4LyHhmoJlTpuRClItLNLfehGpVlJi2qIERxGYEOvr7qTVMEOPtJCY/eMMG0ioioCex/XMw RImoxJ329YwQPwpILNlzHupfUYmXj/+BbRUSiJOYub+DfQKj+CwkR8xCOGIWkiNmITliASPL Kkax4qSizPSMktzEzJx0AyO9jEy9zLzUkk2MkAjK3MG4fKfKIUYBDkYlHl4OKRN/IdbEsuLK 3EOMkhxMSqK81SeBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4rfmAcrwpiZVVqUX5MCkZDg4l Cd6np4BSgkWp6akVaZk5wDQBk2bi4ARp5wFqvwJSw1tckJhbnJkOkT/FKCklznsZJCEAksgo zYPrfcUoDnSkMO9MkCwPMKHBdb0CGsgENDCFyRBkYEkiQkoKmJzYGwVdXr64LJE/5ZRpjZLX 2dLjd6ofHle7t/af68ue+uDbsyTl7jMuYCtatjtxxxqRxx+Y9RdnpZc1O8Y5GxYweenOl1z0 X2yd8gupq1wx01kLjz8Q6jv+833l91meExyYFT0nsFZY9rCa8e0q8I+IvZahOX/h2xT+D08b Q6cdXbU4tHJ2jhJLcUaioRZzUXEiAK0u0EMlAwAA References: <12020915143552_4D9A6@oregon.uoregon.edu> Cc: Joe St Sauver , "therightkey@ietf.org" Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 07:48:27 -0000 DQpPbiAxMCBGZWIgMjAxMiwgYXQgMDE6MjIgLCBTdGVwaGVuIEtlbnQgd3JvdGU6DQo+PiBPciBz aG91bGQgd2UganVzdCBiZSB0cnVzdGluZyBhIGNlcnRpZmljYXRpb24gYXV0aG9yaXR5IHRvIGRv IHdoYXQgaXQNCj4+IHNheXMgaXQgd2lsbCBkbyBpbiBpdHMgQ1BTLCBwZXJoYXBzIGp1c3QgY29u ZmlybWluZyB0aGF0IGFuIGVtYWlsIGFkZHJlc3MNCj4+IGFzc2VydGVkIGluIGEgY2VydGlmaWNh dGUgcmVxdWVzdCBpcyBpbmRlZWQgYWNjZXNzaWJsZSBieSB0aGUgcGFydHkgdGhhdCdzDQo+PiBy ZXF1ZXN0aW5nIGEgY2VydCB3aXRoIHRoYXQgImlkZW50aXR5Ij8NCj4NCj4gVHJ1c3RpbmcgYSBD QSBiYXNlZCBvbiBpdHMgQ1BTLCB3aXRob3V0IGFuIGFiaWxpdHkgdG8gY29uc3RyYWluIHRoZQ0K PiBzY29wZSBvZiBpZGVudGl0aWVzIHRoYXQgdGhlIENBIGNhbiBjZXJ0aWZ5IGlzIGRhbmdlcm91 cy4gVGhpcyBpcyB3aHkNCj4gd2UgaGF2ZSB0aGUgY3VycmVudCBtZXNzIG9mDQoNCg0KSnVzdCB3 YW50ZWQgdG8gc2F5IHRoYXQgdGhvdWdoIHdlIHN0YXJ0ZWQgaW4gc29tZSBkaXNhZ3JlZW1lbnQg YWJvdXQgSUQgZmVkZXJhdGlvbnMsIEknZCBzaWduIHRoYXQgc3RhdGVtZW50IGFuZCBhcHBseSBp dCB0byBpZGVudGl0eSBhc3NlcnRpb25zIGluIGZlZGVyYXRpb25zIGFzIHdlbGwuDQoNCkJlIGdv b2RlLA0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0K RHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9k aWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkg MDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRl IGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUg ZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBz aXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkg Zm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUg YmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lO QVMvZGlzY2xhaW1lci5hc3B4DQo= From stephen.farrell@cs.tcd.ie Fri Feb 10 02:31:50 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5798821F8693 for ; Fri, 10 Feb 2012 02:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Y7KepnPjVpN for ; Fri, 10 Feb 2012 02:31:49 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 06F6121F8674 for ; Fri, 10 Feb 2012 02:31:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 78639171C3A; Fri, 10 Feb 2012 10:31:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1328869906; bh=kCJcT6CLx08ibT D4xkPqPM8/DXtALegOJ/xUk5SKxjU=; b=MVR+Q8VSnb47SvJY4tfkmNjBW0+Feh Iq2rGEyTdDIAhJ4HslKYWST1/1KrXntnKp1zvgNIBkrkYN0w/bQuvPU9cuGaaBgO ENwoGpJY0GWnW3fVEXvt4tT+LeJQBn5rGA//sZ3wmii4c0nxQMMFr9Sfskb0zm7k 3UlsZGrXVtJKkEHWW9mbRGlFUOnIulQNl/FAj2I2DzIbaaNGUuAClrPncle2Qieg qlq70Y4Z/qZP0TA9J9l6LPb57IBkPkUR1g1Uf5JMU5AS78gctTQzKg/4ORJUpCcD kmn4RRW6JHpDznJ62trmDUMecZKQyBh4pghRIGXkPnam1O7mZEyJK0Sw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id mXQwcw9yaioY; Fri, 10 Feb 2012 10:31:46 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AA333171C28; Fri, 10 Feb 2012 10:31:46 +0000 (GMT) Message-ID: <4F34F215.7010405@cs.tcd.ie> Date: Fri, 10 Feb 2012 10:31:49 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] Notes on notaries X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 10:31:50 -0000 Hi Phill, Some subset of this does look like the kind of thing the IETF could do if there are people interested. And we could even do it well, if there are people who'll write code and try deploy stuff as the IETF trundles along. Be good to get a feel for the level of interest in that. Note, a sequence of +1's or -1's is not a helpful response at this stage. Rather, discussion on whether this is a topic we should/could/MUST-NOT take on or whatever is what'd help. (Or, I guess, silence, which would also be telling:-) Ta, S. On 02/09/2012 03:27 PM, Phillip Hallam-Baker wrote: > One component that appears in three of the proposals input to this > discussion is an 'append only' notary. While the precise role and > implementation of the notary changes there are some common features: > > * Use of the Harber/Stornetta catenate certificate approach (aka hash > chains, Merkle trees etc) > * Some notion of 'crowdsourcing' or 'peering' of notaries > > Note that the original Harber/Stornetta patent has expired. There may > be patents still outstanding on specific optimizations but I don't see > any of those as being essential. > > > None of the proposals seem to me to be dependent on a particular > notary implementation. Some are pretty sketchy when it comes to > details. I think this is a feature that could and should be separated > out as a separate problem. > > The uses of a general purpose append-only notary are very significant: > > * Proof of the date that evidence was collected for legal purposes > * Proof that a specific set of contract terms existed on a specific date > * Proof that a Web site delivered specific content on a specific date > > > The reason I think these additional purposes matter is that I think > that a notary service needs to be done right and will require > infrastructure. Specifically, government supported infrastructure. I > am very happy with the idea of walking into NIST or the FBI or the UK > Home office and putting out a case for the reason why USGov or HMG > should invest a $1 million or so on setting up a reference notary for > their country. I don't think the same case can be made for the PKI > proposals being made. > > The reason I want to have government notaries in the mix is that a > government service provides authority that is recognized and > understood by the courts. If Ms Defendant is disputing the digital > evidence being presented by the Metropolitan police claiming it was > modified after they caught her, the court is going to accept a digital > notary stamp that is ultimately validated by a notary service run by > HMG much more easily than one just run by Comodo Inc. In the first > case the evidence is going to be presumed valid without further > consideration, in the second it is highly likely that expert witnesses > etc. will be required. > > > Such a notary service would be the online equivalent of a time service > and would need to be structured in a similar fashion with 'tiers' of > service: > > Tier 1: Master reference notaries run by national laboratories > Tier 2: Service notaries run by commercial entities and universities > Tier 3: Enterprise notaries that serve a specific organization > > Notaries in the top tier would cross-notarize on a regular (e.g. hourly) basis. > Notaries in tier 2 would sync with one (or more) tier 1 notaries on a > regular basis > Notaries in tier 3 would sync with tier 2. > > > I would expect that at least one major university (e.g. CMU, MIT, > whatever) would be willing to support the open source community by > running an open notary service. > > At least one entity in the system should be introducing a stream of > random data into the notarization stream. > > > Such an infrastructure would provide a means of fixing a digital > notarization event between two fixed points in the timeline as > follows: > > First we have to recognize that there is a difference between > 'ordinary' notarization in which a user gets a single document stamped > and 'meta' notarization which is performed between peers. > > > Ordinary Notarization: > > Let the document to be notarized be D, the time be t and the current > witness value from the chosen tier 1, 2, 3 notaries be V1t, V2t, V3t > and the next witness values as V1t', V2t', V3t', the ones after that > Vt'', etc. > > The user submits to the Tier 3 notary, H(D), [identifier of the > meta-timelines fixation is requested against] > Tier 3 notary replies with a URL and a 'delivery date' (which will be > a function of the meta-timelines fixed) > > After the delivery date (typically an hour in the future) the user can > retrieve a proof chain that fixes H(D) with respect to V1t, V2t, V3t > and V3t', and either a proof or a reference to a proof fixing V3t' > with respect to V2t'' and V2t'' with respect to V1t'''. > > The protocol could be adapted to support multiple second and first > tier notaries, but this is complexity without any real benefit. It > does not actually provide any additional security for reasons that > will be explained later. > > The most efficient data structure to use at this level is probably a > Merkle tree. Delaying the delivery of the proof means that the notary > can even choose the optimal approach after the number of items to be > notarized is known. > > > Meta Notarization > > Meta Notarization is the process of fixing tier 1 notaries against > each other. Any notary that engages in the peer notarization is a tier > 1 notary by definition. (this may not be a necessary restriction, can > come back to that). > > Tier 1 notaries may participate in one or more meta-timelines. Each > meta timeline produces a stream of public witness values that is > archived by every member of the timeline. Each meta-timeline > incorporates at least one purely random data source. > > For convenience, all the members of a timeline use the same inputs to > the hash function in the same order. The precise mechanism for doing > this does not matter so much as that they all arrive at the same > result. The simplest implementation would be for one party to act as > the meta notary but politics is likely to intervene and require that > this function is performed on a rotating basis. > > > > Example: > > Alice wishes to fix document X according to the 'Internet' meta-timeline > > 1) Alice submits H(X) to her notary > 2) Some time later, notary responds with the static proof chain > > When Alice needs to use the proof to convince Bob she presents the > static proof chain and either Alice or Bob pulls the current value of > the 'Internet' timeline witness values. > > The most efficient data structure for this layer is probably to use a > skip list. But efficiency 'probably' does not actually matter. > > > The advantage of this structure is that the problem is divided into > two, there is a static component that is immediately fixed and a > variable component that can be cached to a great degree. If we are > thinking of applying this approach to Internet certificates then it is > really not unreasonable for every client that chooses to validate this > data locally to download a few Kb of meta timeline data every single > day. > > > Security analysis > > One of the interesting features of the system is that the notaries are > trustworthy but not trusted. The scope for defection by a notary is > very limited. > > It is desirable to authenticate communications with the notaries but > only to prevent a third party performing a denial of service attack by > introducing bogus data. > > Once a notary has delivered the proof and the client has verified that > it correctly ties to the meta-timeline, the notary becomes irrelevant. > There is nothing that the notary can do to defect. The notary cannot > even perform a denial of service attack. The ability of the tier 2, 3 > notaries to defect is thus bounded in time to the interval between the > request being made and the response being verified. > > The arguments for meta-notaries are a little more complex but again > the notary can only defect by refusing service or corrupting > > Any client relying on verifying notary data is going to have to be > capable of adapting to the fact that the chosen meta-timeline might > disappear at a future date so the denial of service attack is not > particularly worrying. > > > Meta-Timelines can change over time and the protocol needs to be able > to cope with this. Specifically a meta-timeline can fork if some > parties decide to leave. But this just requires that the successor > timelines to agree on clear identifiers so that they do not become > ambiguous. > > Timelines can also merge. All this requires is for the last witness > value of one meta timeline to be input to another. Which is the way > that a Meta-Timeline should be decommissioned in an orderly fashion. > In fact, it is desirable for there to be multiple meta-timelines and > for them to fix themselves against each other on a regular basis in > case of a sudden and unexpected failure or breach. > From tom@ritter.vg Fri Feb 10 06:04:15 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3922121F8664 for ; Fri, 10 Feb 2012 06:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoF6Gna6AoVZ for ; Fri, 10 Feb 2012 06:04:11 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3290B21F8631 for ; Fri, 10 Feb 2012 06:04:01 -0800 (PST) Received: by lahl5 with SMTP id l5so2860245lah.31 for ; Fri, 10 Feb 2012 06:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=7XabayandryEBkFoyqrYvlKagh497RYjizajZoDdqRs=; b=lHNZdsD+Jqn/LEaDAHkzg97u0kdsJcmpZSW19clJV5khXy/ASvirv4r6XmumwlQy76 UX+maVDh9vSGstWZ51Gjt1KDk5pxm5W8JMqK0FaS7KbF25zpE1mx+Yl6v/cmffL377z6 GE5yOzppkXcvc0Gq9uSM+sempA0s8Mxw53gE4= Received: by 10.152.111.137 with SMTP id ii9mr4162804lab.39.1328882641131; Fri, 10 Feb 2012 06:04:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.11.67 with HTTP; Fri, 10 Feb 2012 06:03:41 -0800 (PST) In-Reply-To: <4F34F215.7010405@cs.tcd.ie> References: <4F34F215.7010405@cs.tcd.ie> From: Tom Ritter Date: Fri, 10 Feb 2012 09:03:41 -0500 Message-ID: To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkHEVVS5VYVYkE/jwrhitSR4hK3Ido3ELt8zh0kjVzYVUwZ9EoS2OBq5ycGfyc426s5Sems Subject: Re: [therightkey] Notes on notaries X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 14:04:15 -0000 Was anyone involved with or aware of this Working Group, or it's published documents: http://www.ietf.org/wg/concluded/ltans.html ? A very crude notary service I remember was a simple one that was designed to receive a lot of automated email, and would produce hashes of them that would build up in a tree. The tree-hashes were distributed far and wide via a mailing list. The idea was you would submit your own hashes, and then be able to provide the message that resulted in the hash at your leisure. The timestamp would be proven by this third party service by the relatively simple notion of "This thing has it in its database at this time, and the 10,000 subscribers have the same data, and it's unreasonable for all of them to collude to disprove my single hash out of the thousands they receive a day." I can't for the life of me remember who ran or what this service was called - but it was an actual, running, website - not just an academic paper. Anyway, I've wanted such a service to return for a long time. The security research community emulates today by posting hashes to twitter. -tom On 10 February 2012 05:31, Stephen Farrell wrote: > > Hi Phill, > > Some subset of this does look like the kind of thing the > IETF could do if there are people interested. And we could > even do it well, if there are people who'll write code and > try deploy stuff as the IETF trundles along. > > Be good to get a feel for the level of interest in that. > > Note, a sequence of +1's or -1's is not a helpful response > at this stage. Rather, discussion on whether this is a topic > we should/could/MUST-NOT take on or whatever is what'd help. > (Or, I guess, silence, which would also be telling:-) > > Ta, > S. > > > On 02/09/2012 03:27 PM, Phillip Hallam-Baker wrote: >> >> One component that appears in three of the proposals input to this >> discussion is an 'append only' notary. While the precise role and >> implementation of the notary changes there are some common features: >> >> * Use of the Harber/Stornetta catenate certificate approach (aka hash >> chains, Merkle trees etc) >> * Some notion of 'crowdsourcing' or 'peering' of notaries >> >> Note that the original Harber/Stornetta patent has expired. There may >> be patents still outstanding on specific optimizations but I don't see >> any of those as being essential. >> >> >> None of the proposals seem to me to be dependent on a particular >> notary implementation. Some are pretty sketchy when it comes to >> details. I think this is a feature that could and should be separated >> out as a separate problem. >> >> The uses of a general purpose append-only notary are very significant: >> >> * Proof of the date that evidence was collected for legal purposes >> * Proof that a specific set of contract terms existed on a specific date >> * Proof that a Web site delivered specific content on a specific date >> >> >> The reason I think these additional purposes matter is that I think >> that a notary service needs to be done right and will require >> infrastructure. Specifically, government supported infrastructure. I >> am very happy with the idea of walking into NIST or the FBI or the UK >> Home office and putting out a case for the reason why USGov or HMG >> should invest a $1 million or so on setting up a reference notary for >> their country. I don't think the same case can be made for the PKI >> proposals being made. >> >> The reason I want to have government notaries in the mix is that a >> government service provides authority that is recognized and >> understood by the courts. If Ms Defendant is disputing the digital >> evidence being presented by the Metropolitan police claiming it was >> modified after they caught her, the court is going to accept a digital >> notary stamp that is ultimately validated by a notary service run by >> HMG much more easily than one just run by Comodo Inc. In the first >> case the evidence is going to be presumed valid without further >> consideration, in the second it is highly likely that expert witnesses >> etc. will be required. >> >> >> Such a notary service would be the online equivalent of a time service >> and would need to be structured in a similar fashion with 'tiers' of >> service: >> >> Tier 1: Master reference notaries run by national laboratories >> Tier 2: Service notaries run by commercial entities and universities >> Tier 3: Enterprise notaries that serve a specific organization >> >> Notaries in the top tier would cross-notarize on a regular (e.g. hourly) >> basis. >> Notaries in tier 2 would sync with one (or more) tier 1 notaries on a >> regular basis >> Notaries in tier 3 would sync with tier 2. >> >> >> I would expect that at least one major university (e.g. CMU, MIT, >> whatever) would be willing to support the open source community by >> running an open notary service. >> >> At least one entity in the system should be introducing a stream of >> random data into the notarization stream. >> >> >> Such an infrastructure would provide a means of fixing a digital >> notarization event between two fixed points in the timeline as >> follows: >> >> First we have to recognize that there is a difference between >> 'ordinary' notarization in which a user gets a single document stamped >> and 'meta' notarization which is performed between peers. >> >> >> Ordinary Notarization: >> >> Let the document to be notarized be D, the time be t and the current >> witness value from the chosen tier 1, 2, 3 notaries be V1t, V2t, V3t >> and the next witness values as V1t', V2t', V3t', the ones after that >> Vt'', etc. >> >> The user submits to the Tier 3 notary, H(D), [identifier of the >> meta-timelines fixation is requested against] >> Tier 3 notary replies with a URL and a 'delivery date' (which will be >> a function of the meta-timelines fixed) >> >> After the delivery date (typically an hour in the future) the user can >> retrieve a proof chain that fixes H(D) with respect to V1t, V2t, V3t >> and V3t', and either a proof or a reference to a proof fixing V3t' >> with respect to V2t'' and V2t'' with respect to V1t'''. >> >> The protocol could be adapted to support multiple second and first >> tier notaries, but this is complexity without any real benefit. It >> does not actually provide any additional security for reasons that >> will be explained later. >> >> The most efficient data structure to use at this level is probably a >> Merkle tree. Delaying the delivery of the proof means that the notary >> can even choose the optimal approach after the number of items to be >> notarized is known. >> >> >> Meta Notarization >> >> Meta Notarization is the process of fixing tier 1 notaries against >> each other. Any notary that engages in the peer notarization is a tier >> 1 notary by definition. (this may not be a necessary restriction, can >> come back to that). >> >> Tier 1 notaries may participate in one or more meta-timelines. Each >> meta timeline produces a stream of public witness values that is >> archived by every member of the timeline. Each meta-timeline >> incorporates at least one purely random data source. >> >> For convenience, all the members of a timeline use the same inputs to >> the hash function in the same order. The precise mechanism for doing >> this does not matter so much as that they all arrive at the same >> result. The simplest implementation would be for one party to act as >> the meta notary but politics is likely to intervene and require that >> this function is performed on a rotating basis. >> >> >> >> Example: >> >> Alice wishes to fix document X according to the 'Internet' meta-timeline >> >> 1) Alice submits H(X) to her notary >> 2) Some time later, notary responds with the static proof chain >> >> When Alice needs to use the proof to convince Bob she presents the >> static proof chain and either Alice or Bob pulls the current value of >> the 'Internet' timeline witness values. >> >> The most efficient data structure for this layer is probably to use a >> skip list. But efficiency 'probably' does not actually matter. >> >> >> The advantage of this structure is that the problem is divided into >> two, there is a static component that is immediately fixed and a >> variable component that can be cached to a great degree. If we are >> thinking of applying this approach to Internet certificates then it is >> really not unreasonable for every client that chooses to validate this >> data locally to download a few Kb of meta timeline data every single >> day. >> >> >> Security analysis >> >> One of the interesting features of the system is that the notaries are >> trustworthy but not trusted. The scope for defection by a notary is >> very limited. >> >> It is desirable to authenticate communications with the notaries but >> only to prevent a third party performing a denial of service attack by >> introducing bogus data. >> >> Once a notary has delivered the proof and the client has verified that >> it correctly ties to the meta-timeline, the notary becomes irrelevant. >> There is nothing that the notary can do to defect. The notary cannot >> even perform a denial of service attack. The ability of the tier 2, 3 >> notaries to defect is thus bounded in time to the interval between the >> request being made and the response being verified. >> >> The arguments for meta-notaries are a little more complex but again >> the notary can only defect by refusing service or corrupting >> >> Any client relying on verifying notary data is going to have to be >> capable of adapting to the fact that the chosen meta-timeline might >> disappear at a future date so the denial of service attack is not >> particularly worrying. >> >> >> Meta-Timelines can change over time and the protocol needs to be able >> to cope with this. Specifically a meta-timeline can fork if some >> parties decide to leave. But this just requires that the successor >> timelines to agree on clear identifiers so that they do not become >> ambiguous. >> >> Timelines can also merge. All this requires is for the last witness >> value of one meta timeline to be input to another. Which is the way >> that a Meta-Timeline should be decommissioned in an orderly fashion. >> In fact, it is desirable for there to be multiple meta-timelines and >> for them to fix themselves against each other on a regular basis in >> case of a sudden and unexpected failure or breach. >> > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From hallam@gmail.com Fri Feb 10 06:05:36 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9903F21F86A8 for ; Fri, 10 Feb 2012 06:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUerlr9PunYk for ; Fri, 10 Feb 2012 06:05:35 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0430721F865F for ; Fri, 10 Feb 2012 06:05:34 -0800 (PST) Received: by ggnq2 with SMTP id q2so1688939ggn.31 for ; Fri, 10 Feb 2012 06:05:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YCsrqVCo4jKoiPd8vHsydfgtV66P8iPSYQe0qZjGQ48=; b=ihS98rghNKQACYMiQXBBh6WdSzCiYXr6B13PpRYe563h02JxWNnAcRP4N+dOYj/qF+ nDP8UHTJzeG2cH54jjCEdzLb7m/Z9Q3c2szhRqZKjlRQlK3+LAxiHx0kXX2X5isXJjDt ysgQbDZot2i/eU6GFsVjuReP5RW0P+Sdi52PY= MIME-Version: 1.0 Received: by 10.50.153.233 with SMTP id vj9mr11172079igb.16.1328882733837; Fri, 10 Feb 2012 06:05:33 -0800 (PST) Received: by 10.182.75.138 with HTTP; Fri, 10 Feb 2012 06:05:33 -0800 (PST) In-Reply-To: <4F34F215.7010405@cs.tcd.ie> References: <4F34F215.7010405@cs.tcd.ie> Date: Fri, 10 Feb 2012 09:05:33 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: therightkey@ietf.org Subject: Re: [therightkey] Notes on notaries X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 14:05:36 -0000 I think there are a number of questions 1) Is there a need for a general purpose catenate certificate notary protocol? 2) Is there benefit to using one within a 'right key' solution? 2a) Is there benefit to performing the verification at the client edge? 2b) Should the right key use the same notary infrastructure as other applications? 2c) Should the 'right key' notary mechanism be a one off or make use of a general purpose mechanism? My view is: 1) Absolutely yes. There is a very clear need for such a protocol to protect digital evidence in legal case and for photographs taken by journalists, etc. etc. 2) Probably can't hurt, we have three proposals to do just that 2a) I am really rather dubious that verification at the edge would be widely implemented. Or rather I think that people would write the code, deploy the code but never turn on the hard fail option. Call me a cynic but why should this time be different? 2b) I can't see any special requirement for the 'right key' case protocol wise. I can't really see right key having the critical mass necessary to build out its own separate infrastructure and even if it did try to, I can't see how other purposes could be kept out of it. So my view is that we should think in terms of there being one notary infrastructure and any right key use using it. 2c) Given the answer to 2b, I think it is clear that we need one protocol document - unless we discover otherwise while trying to build it. On Fri, Feb 10, 2012 at 5:31 AM, Stephen Farrell wrote: > > Hi Phill, > > Some subset of this does look like the kind of thing the > IETF could do if there are people interested. And we could > even do it well, if there are people who'll write code and > try deploy stuff as the IETF trundles along. > > Be good to get a feel for the level of interest in that. > > Note, a sequence of +1's or -1's is not a helpful response > at this stage. Rather, discussion on whether this is a topic > we should/could/MUST-NOT take on or whatever is what'd help. > (Or, I guess, silence, which would also be telling:-) > > Ta, > S. > > > On 02/09/2012 03:27 PM, Phillip Hallam-Baker wrote: >> >> One component that appears in three of the proposals input to this >> discussion is an 'append only' notary. While the precise role and >> implementation of the notary changes there are some common features: >> >> * Use of the Harber/Stornetta catenate certificate approach (aka hash >> chains, Merkle trees etc) >> * Some notion of 'crowdsourcing' or 'peering' of notaries >> >> Note that the original Harber/Stornetta patent has expired. There may >> be patents still outstanding on specific optimizations but I don't see >> any of those as being essential. >> >> >> None of the proposals seem to me to be dependent on a particular >> notary implementation. Some are pretty sketchy when it comes to >> details. I think this is a feature that could and should be separated >> out as a separate problem. >> >> The uses of a general purpose append-only notary are very significant: >> >> * Proof of the date that evidence was collected for legal purposes >> * Proof that a specific set of contract terms existed on a specific date >> * Proof that a Web site delivered specific content on a specific date >> >> >> The reason I think these additional purposes matter is that I think >> that a notary service needs to be done right and will require >> infrastructure. Specifically, government supported infrastructure. I >> am very happy with the idea of walking into NIST or the FBI or the UK >> Home office and putting out a case for the reason why USGov or HMG >> should invest a $1 million or so on setting up a reference notary for >> their country. I don't think the same case can be made for the PKI >> proposals being made. >> >> The reason I want to have government notaries in the mix is that a >> government service provides authority that is recognized and >> understood by the courts. If Ms Defendant is disputing the digital >> evidence being presented by the Metropolitan police claiming it was >> modified after they caught her, the court is going to accept a digital >> notary stamp that is ultimately validated by a notary service run by >> HMG much more easily than one just run by Comodo Inc. In the first >> case the evidence is going to be presumed valid without further >> consideration, in the second it is highly likely that expert witnesses >> etc. will be required. >> >> >> Such a notary service would be the online equivalent of a time service >> and would need to be structured in a similar fashion with 'tiers' of >> service: >> >> Tier 1: Master reference notaries run by national laboratories >> Tier 2: Service notaries run by commercial entities and universities >> Tier 3: Enterprise notaries that serve a specific organization >> >> Notaries in the top tier would cross-notarize on a regular (e.g. hourly) >> basis. >> Notaries in tier 2 would sync with one (or more) tier 1 notaries on a >> regular basis >> Notaries in tier 3 would sync with tier 2. >> >> >> I would expect that at least one major university (e.g. CMU, MIT, >> whatever) would be willing to support the open source community by >> running an open notary service. >> >> At least one entity in the system should be introducing a stream of >> random data into the notarization stream. >> >> >> Such an infrastructure would provide a means of fixing a digital >> notarization event between two fixed points in the timeline as >> follows: >> >> First we have to recognize that there is a difference between >> 'ordinary' notarization in which a user gets a single document stamped >> and 'meta' notarization which is performed between peers. >> >> >> Ordinary Notarization: >> >> Let the document to be notarized be D, the time be t and the current >> witness value from the chosen tier 1, 2, 3 notaries be V1t, V2t, V3t >> and the next witness values as V1t', V2t', V3t', the ones after that >> Vt'', etc. >> >> The user submits to the Tier 3 notary, H(D), [identifier of the >> meta-timelines fixation is requested against] >> Tier 3 notary replies with a URL and a 'delivery date' (which will be >> a function of the meta-timelines fixed) >> >> After the delivery date (typically an hour in the future) the user can >> retrieve a proof chain that fixes H(D) with respect to V1t, V2t, V3t >> and V3t', and either a proof or a reference to a proof fixing V3t' >> with respect to V2t'' and V2t'' with respect to V1t'''. >> >> The protocol could be adapted to support multiple second and first >> tier notaries, but this is complexity without any real benefit. It >> does not actually provide any additional security for reasons that >> will be explained later. >> >> The most efficient data structure to use at this level is probably a >> Merkle tree. Delaying the delivery of the proof means that the notary >> can even choose the optimal approach after the number of items to be >> notarized is known. >> >> >> Meta Notarization >> >> Meta Notarization is the process of fixing tier 1 notaries against >> each other. Any notary that engages in the peer notarization is a tier >> 1 notary by definition. (this may not be a necessary restriction, can >> come back to that). >> >> Tier 1 notaries may participate in one or more meta-timelines. Each >> meta timeline produces a stream of public witness values that is >> archived by every member of the timeline. Each meta-timeline >> incorporates at least one purely random data source. >> >> For convenience, all the members of a timeline use the same inputs to >> the hash function in the same order. The precise mechanism for doing >> this does not matter so much as that they all arrive at the same >> result. The simplest implementation would be for one party to act as >> the meta notary but politics is likely to intervene and require that >> this function is performed on a rotating basis. >> >> >> >> Example: >> >> Alice wishes to fix document X according to the 'Internet' meta-timeline >> >> 1) Alice submits H(X) to her notary >> 2) Some time later, notary responds with the static proof chain >> >> When Alice needs to use the proof to convince Bob she presents the >> static proof chain and either Alice or Bob pulls the current value of >> the 'Internet' timeline witness values. >> >> The most efficient data structure for this layer is probably to use a >> skip list. But efficiency 'probably' does not actually matter. >> >> >> The advantage of this structure is that the problem is divided into >> two, there is a static component that is immediately fixed and a >> variable component that can be cached to a great degree. If we are >> thinking of applying this approach to Internet certificates then it is >> really not unreasonable for every client that chooses to validate this >> data locally to download a few Kb of meta timeline data every single >> day. >> >> >> Security analysis >> >> One of the interesting features of the system is that the notaries are >> trustworthy but not trusted. The scope for defection by a notary is >> very limited. >> >> It is desirable to authenticate communications with the notaries but >> only to prevent a third party performing a denial of service attack by >> introducing bogus data. >> >> Once a notary has delivered the proof and the client has verified that >> it correctly ties to the meta-timeline, the notary becomes irrelevant. >> There is nothing that the notary can do to defect. The notary cannot >> even perform a denial of service attack. The ability of the tier 2, 3 >> notaries to defect is thus bounded in time to the interval between the >> request being made and the response being verified. >> >> The arguments for meta-notaries are a little more complex but again >> the notary can only defect by refusing service or corrupting >> >> Any client relying on verifying notary data is going to have to be >> capable of adapting to the fact that the chosen meta-timeline might >> disappear at a future date so the denial of service attack is not >> particularly worrying. >> >> >> Meta-Timelines can change over time and the protocol needs to be able >> to cope with this. Specifically a meta-timeline can fork if some >> parties decide to leave. But this just requires that the successor >> timelines to agree on clear identifiers so that they do not become >> ambiguous. >> >> Timelines can also merge. All this requires is for the last witness >> value of one meta timeline to be input to another. Which is the way >> that a Meta-Timeline should be decommissioned in an orderly fashion. >> In fact, it is desirable for there to be multiple meta-timelines and >> for them to fix themselves against each other on a regular basis in >> case of a sudden and unexpected failure or breach. >> > -- Website: http://hallambaker.com/ From hallam@gmail.com Fri Feb 10 06:13:43 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEB521F8633 for ; Fri, 10 Feb 2012 06:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.364 X-Spam-Level: X-Spam-Status: No, score=-3.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf4MRNcXbbn6 for ; Fri, 10 Feb 2012 06:13:41 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CDCC921F86CA for ; Fri, 10 Feb 2012 06:13:22 -0800 (PST) Received: by obbwd15 with SMTP id wd15so4580170obb.31 for ; Fri, 10 Feb 2012 06:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AXO3fzOynHWriWDkoOPtHkLYRw2fvTA+zBlVOk6JvIs=; b=Hvjy31zXBbhXxc/QRs4SJXoTv+8EPUyGVTNOCVoazRLiwC+NzrqXLRzS+9RWCMxTWZ 8GdTgLU5ME79BUIl7unhxRmh/Qp8gYe6gkeW3x5GKSmwunaMY+RzqRo3QnlpFLOzLoEZ /15NpT3MWnViYLXt/WPTF27GTzDwTwp8qSTHU= MIME-Version: 1.0 Received: by 10.50.153.233 with SMTP id vj9mr11233644igb.16.1328883191962; Fri, 10 Feb 2012 06:13:11 -0800 (PST) Received: by 10.182.75.138 with HTTP; Fri, 10 Feb 2012 06:13:11 -0800 (PST) In-Reply-To: References: <4F34F215.7010405@cs.tcd.ie> Date: Fri, 10 Feb 2012 09:13:11 -0500 Message-ID: From: Phillip Hallam-Baker To: Tom Ritter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: therightkey@ietf.org Subject: Re: [therightkey] Notes on notaries X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 14:13:43 -0000 Yes, I am aware of them. The problem with LTANS was that the catenate cert technology was still encumbered at the time and there was a company formed to exploit the patents that was very aggressive in filing lawsuits, including lawsuits over stuff that they clearly had no claim to. I was just going through the LTANS work to see if there was stuff we could = use. The big reason to not use LTANS is that they use XML signature. It made sense for their approach but I don't see it as really working very well with the catenate technology. You would have to fire up an XML parser on each hop. On Fri, Feb 10, 2012 at 9:03 AM, Tom Ritter wrote: > Was anyone involved with or aware of this Working Group, or it's > published documents: http://www.ietf.org/wg/concluded/ltans.html ? > > A very crude notary service I remember was a simple one that was > designed to receive a lot of automated email, and would produce hashes > of them that would build up in a tree. =A0The tree-hashes were > distributed far and wide via a mailing list. =A0The idea was you would > submit your own hashes, and then be able to provide the message that > resulted in the hash at your leisure. =A0The timestamp would be proven > by this third party service by the relatively simple notion of "This > thing has it in its database at this time, and the 10,000 subscribers > have the same data, and it's unreasonable for all of them to collude > to disprove my single hash out of the thousands they receive a day." > > I can't for the life of me remember who ran or what this service was > called - but it was an actual, running, website - not just an academic > paper. > > Anyway, I've wanted such a service to return for a long time. =A0The > security research community emulates today by posting hashes to > twitter. > > -tom > > > > On 10 February 2012 05:31, Stephen Farrell wr= ote: >> >> Hi Phill, >> >> Some subset of this does look like the kind of thing the >> IETF could do if there are people interested. And we could >> even do it well, if there are people who'll write code and >> try deploy stuff as the IETF trundles along. >> >> Be good to get a feel for the level of interest in that. >> >> Note, a sequence of +1's or -1's is not a helpful response >> at this stage. Rather, discussion on whether this is a topic >> we should/could/MUST-NOT take on or whatever is what'd help. >> (Or, I guess, silence, which would also be telling:-) >> >> Ta, >> S. >> >> >> On 02/09/2012 03:27 PM, Phillip Hallam-Baker wrote: >>> >>> One component that appears in three of the proposals input to this >>> discussion is an 'append only' notary. While the precise role and >>> implementation of the notary changes there are some common features: >>> >>> * Use of the Harber/Stornetta catenate certificate approach (aka hash >>> chains, Merkle trees etc) >>> * Some notion of 'crowdsourcing' or 'peering' of notaries >>> >>> Note that the original Harber/Stornetta patent has expired. There may >>> be patents still outstanding on specific optimizations but I don't see >>> any of those as being essential. >>> >>> >>> None of the proposals seem to me to be dependent on a particular >>> notary implementation. Some are pretty sketchy when it comes to >>> details. I think this is a feature that could and should be separated >>> out as a separate problem. >>> >>> The uses of a general purpose append-only notary are very significant: >>> >>> * Proof of the date that evidence was collected for legal purposes >>> * Proof that a specific set of contract terms existed on a specific dat= e >>> * Proof that a Web site delivered specific content on a specific date >>> >>> >>> The reason I think these additional purposes matter is that I think >>> that a notary service needs to be done right and will require >>> infrastructure. Specifically, government supported infrastructure. I >>> am very happy with the idea of walking into NIST or the FBI or the UK >>> Home office and putting out a case for the reason why USGov or HMG >>> should invest a $1 million or so on setting up a reference notary for >>> their country. I don't think the same case can be made for the PKI >>> proposals being made. >>> >>> The reason I want to have government notaries in the mix is that a >>> government service provides authority that is recognized and >>> understood by the courts. If Ms Defendant is disputing the digital >>> evidence being presented by the Metropolitan police claiming it was >>> modified after they caught her, the court is going to accept a digital >>> notary stamp that is ultimately validated by a notary service run by >>> HMG much more easily than one just run by Comodo Inc. In the first >>> case the evidence is going to be presumed valid without further >>> consideration, in the second it is highly likely that expert witnesses >>> etc. will be required. >>> >>> >>> Such a notary service would be the online equivalent of a time service >>> and would need to be structured in a similar fashion with 'tiers' of >>> service: >>> >>> Tier 1: Master reference notaries run by national laboratories >>> Tier 2: Service notaries run by commercial entities and universities >>> Tier 3: Enterprise notaries that serve a specific organization >>> >>> Notaries in the top tier would cross-notarize on a regular (e.g. hourly= ) >>> basis. >>> Notaries in tier 2 would sync with one (or more) tier 1 notaries on a >>> regular basis >>> Notaries in tier 3 would sync with tier 2. >>> >>> >>> I would expect that at least one major university (e.g. CMU, MIT, >>> whatever) would be willing to support the open source community by >>> running an open notary service. >>> >>> At least one entity in the system should be introducing a stream of >>> random data into the notarization stream. >>> >>> >>> Such an infrastructure would provide a means of fixing a digital >>> notarization event between two fixed points in the timeline as >>> follows: >>> >>> First we have to recognize that there is a difference between >>> 'ordinary' notarization in which a user gets a single document stamped >>> and 'meta' notarization which is performed between peers. >>> >>> >>> Ordinary Notarization: >>> >>> Let the document to be notarized be D, the time be t and the current >>> witness value from the chosen tier 1, 2, 3 notaries be V1t, V2t, V3t >>> and the next witness values as V1t', V2t', V3t', the ones after that >>> Vt'', etc. >>> >>> The user submits to the Tier 3 notary, H(D), [identifier of the >>> meta-timelines fixation is requested against] >>> Tier 3 notary replies with a URL and a 'delivery date' (which will be >>> a function of the meta-timelines fixed) >>> >>> After the delivery date (typically an hour in the future) the user can >>> retrieve a proof chain that fixes H(D) with respect to V1t, V2t, V3t >>> and V3t', and either a proof or a reference to a proof fixing V3t' >>> with respect to V2t'' and V2t'' with respect to V1t'''. >>> >>> The protocol could be adapted to support multiple second and first >>> tier notaries, but this is complexity without any real benefit. It >>> does not actually provide any additional security for reasons that >>> will be explained later. >>> >>> The most efficient data structure to use at this level is probably a >>> Merkle tree. Delaying the delivery of the proof means that the notary >>> can even choose the optimal approach after the number of items to be >>> notarized is known. >>> >>> >>> Meta Notarization >>> >>> Meta Notarization is the process of fixing tier 1 notaries against >>> each other. Any notary that engages in the peer notarization is a tier >>> 1 notary by definition. (this may not be a necessary restriction, can >>> come back to that). >>> >>> Tier 1 notaries may participate in one or more meta-timelines. Each >>> meta timeline produces a stream of public witness values that is >>> archived by every member of the timeline. Each meta-timeline >>> incorporates at least one purely random data source. >>> >>> For convenience, all the members of a timeline use the same inputs to >>> the hash function in the same order. The precise mechanism for doing >>> this does not matter so much as that they all arrive at the same >>> result. The simplest implementation would be for one party to act as >>> the meta notary but politics is likely to intervene and require that >>> this function is performed on a rotating basis. >>> >>> >>> >>> Example: >>> >>> Alice wishes to fix document X according to the 'Internet' meta-timelin= e >>> >>> 1) Alice submits H(X) to her notary >>> 2) Some time later, notary responds with the static proof chain >>> >>> When Alice needs to use the proof to convince Bob she presents the >>> static proof chain and either Alice or Bob pulls the current value of >>> the 'Internet' timeline witness values. >>> >>> The most efficient data structure for this layer is probably to use a >>> skip list. But efficiency 'probably' does not actually matter. >>> >>> >>> The advantage of this structure is that the problem is divided into >>> two, there is a static component that is immediately fixed and a >>> variable component that can be cached to a great degree. If we are >>> thinking of applying this approach to Internet certificates then it is >>> really not unreasonable for every client that chooses to validate this >>> data locally to download a few Kb of meta timeline data every single >>> day. >>> >>> >>> Security analysis >>> >>> One of the interesting features of the system is that the notaries are >>> trustworthy but not trusted. The scope for defection by a notary is >>> very limited. >>> >>> It is desirable to authenticate communications with the notaries but >>> only to prevent a third party performing a denial of service attack by >>> introducing bogus data. >>> >>> Once a notary has delivered the proof and the client has verified that >>> it correctly ties to the meta-timeline, the notary becomes irrelevant. >>> There is nothing that the notary can do to defect. The notary cannot >>> even perform a denial of service attack. The ability of the tier 2, 3 >>> notaries to defect is thus bounded in time to the interval between the >>> request being made and the response being verified. >>> >>> The arguments for meta-notaries are a little more complex but again >>> the notary can only defect by refusing service or corrupting >>> >>> Any client relying on verifying notary data is going to have to be >>> capable of adapting to the fact that the chosen meta-timeline might >>> disappear at a future date so the denial of service attack is not >>> particularly worrying. >>> >>> >>> Meta-Timelines can change over time and the protocol needs to be able >>> to cope with this. Specifically a meta-timeline can fork if some >>> parties decide to leave. But this just requires that the successor >>> timelines to agree on clear identifiers so that they do not become >>> ambiguous. >>> >>> Timelines can also merge. All this requires is for the last witness >>> value of one meta timeline to be input to another. Which is the way >>> that a Meta-Timeline should be decommissioned in an orderly fashion. >>> In fact, it is desirable for there to be multiple meta-timelines and >>> for them to fix themselves against each other on a regular basis in >>> case of a sudden and unexpected failure or breach. >>> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --=20 Website: http://hallambaker.com/ From carl@redhoundsoftware.com Fri Feb 10 06:19:25 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B91F21F8757 for ; Fri, 10 Feb 2012 06:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7v+S3JRO4Sya for ; Fri, 10 Feb 2012 06:19:24 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C14B021F8749 for ; Fri, 10 Feb 2012 06:19:24 -0800 (PST) Received: by qcsg13 with SMTP id g13so1857292qcs.31 for ; Fri, 10 Feb 2012 06:19:24 -0800 (PST) Received: by 10.229.78.203 with SMTP id m11mr4447641qck.86.1328883564153; Fri, 10 Feb 2012 06:19:24 -0800 (PST) Received: from [192.168.1.4] (pool-173-79-172-61.washdc.fios.verizon.net. [173.79.172.61]) by mx.google.com with ESMTPS id fd1sm13148144qab.1.2012.02.10.06.19.23 (version=SSLv3 cipher=OTHER); Fri, 10 Feb 2012 06:19:23 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 10 Feb 2012 09:19:19 -0500 From: Carl Wallace To: Phillip Hallam-Baker , Tom Ritter Message-ID: Thread-Topic: [therightkey] Notes on notaries In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQmiUXN/l1F2Kob62bh8mtKNj6y82H2hUnxrbzp8nlw2U2fJzoPNH5X6DB2kzgLdAQAUNAfj Cc: therightkey@ietf.org Subject: Re: [therightkey] Notes on notaries X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 14:19:25 -0000 On 2/10/12 9:13 AM, "Phillip Hallam-Baker" wrote: >Yes, I am aware of them. > >The problem with LTANS was that the catenate cert technology was still >encumbered at the time and there was a company formed to exploit the >patents that was very aggressive in filing lawsuits, including >lawsuits over stuff that they clearly had no claim to. > > >I was just going through the LTANS work to see if there was stuff we >could use. > >The big reason to not use LTANS is that they use XML signature. It >made sense for their approach but I don't see it as really working >very well with the catenate technology. You would have to fire up an >XML parser on each hop. There were two evidence record formats defined by LTANS, one in ASN.1 and (later) one in XML. http://tools.ietf.org/html/rfc4998 - ERS http://tools.ietf.org/html/rfc6283 - XMLERS From hallam@gmail.com Fri Feb 10 08:19:50 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90EE21F8703 for ; Fri, 10 Feb 2012 08:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.368 X-Spam-Level: X-Spam-Status: No, score=-3.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh5k3V5Lf9+Y for ; Fri, 10 Feb 2012 08:19:49 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 71ABB21F86F1 for ; Fri, 10 Feb 2012 08:19:49 -0800 (PST) Received: by yenm3 with SMTP id m3so1807512yen.31 for ; Fri, 10 Feb 2012 08:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QysVx4dHOZlQBzTnJsplA3xa7M0VMN/FGNlxtBaDjUA=; b=Q+pG9p7TU63ng329R01vb0/E0kUzEfCYDW6Fnv6nbVJqJ0g6SWxtcMNh+S1F4XstIc YKPlevgl9uKbSDEHQrfn63sOa+FXSUngZ/1cRBC1idrdndkfWklZFiQmIA5rV6Z1S/xC hlcJapWvMBvpeC6pN/2wdX2DXoKcYBYJt/e80= MIME-Version: 1.0 Received: by 10.50.153.233 with SMTP id vj9mr12243929igb.16.1328890788882; Fri, 10 Feb 2012 08:19:48 -0800 (PST) Received: by 10.182.75.138 with HTTP; Fri, 10 Feb 2012 08:19:48 -0800 (PST) In-Reply-To: References: Date: Fri, 10 Feb 2012 11:19:48 -0500 Message-ID: From: Phillip Hallam-Baker To: Carl Wallace Content-Type: text/plain; charset=ISO-8859-1 Cc: therightkey@ietf.org, Tom Ritter Subject: Re: [therightkey] Notes on notaries X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 16:19:51 -0000 Ah, that is much better. It looks to me as if the authors may have had the idea of migrating to a catenate scheme at some later date. After all the catenate scheme is arguably merely a variation on the Merkle tree. I am trying to work out if perhaps a profile of ERS would work.. There is a provision to add attributes to entries in the ArchiveTimeStamp data structure: ArchiveTimeStamp ::= SEQUENCE { digestAlgorithm [0] AlgorithmIdentifier OPTIONAL, attributes [1] Attributes OPTIONAL, reducedHashtree [2] SEQUENCE OF PartialHashtree OPTIONAL, timeStamp ContentInfo} PartialHashtree ::= SEQUENCE OF OCTET STRING Attributes ::= SET SIZE (1..MAX) OF Attribute So maybe all that would need to be added is some way to add in info to identify a particular hash as being catenate, coming from another notary, etc. On Fri, Feb 10, 2012 at 9:19 AM, Carl Wallace wrote: > > On 2/10/12 9:13 AM, "Phillip Hallam-Baker" wrote: > >>Yes, I am aware of them. >> >>The problem with LTANS was that the catenate cert technology was still >>encumbered at the time and there was a company formed to exploit the >>patents that was very aggressive in filing lawsuits, including >>lawsuits over stuff that they clearly had no claim to. >> >> >>I was just going through the LTANS work to see if there was stuff we >>could use. >> >>The big reason to not use LTANS is that they use XML signature. It >>made sense for their approach but I don't see it as really working >>very well with the catenate technology. You would have to fire up an >>XML parser on each hop. > > There were two evidence record formats defined by LTANS, one in ASN.1 and > (later) one in XML. > > http://tools.ietf.org/html/rfc4998 - ERS > > http://tools.ietf.org/html/rfc6283 - XMLERS > > > -- Website: http://hallambaker.com/ From aerowolf@gmail.com Fri Feb 10 18:12:24 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9800921F8484 for ; Fri, 10 Feb 2012 18:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=1.277, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcUzWAkYZPkk for ; Fri, 10 Feb 2012 18:12:23 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81CCA21F8433 for ; Fri, 10 Feb 2012 18:12:23 -0800 (PST) Received: by iagf6 with SMTP id f6so1253950iag.31 for ; Fri, 10 Feb 2012 18:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=3mW2OrUYhJaSS3esoxTRM0NI0ODHOBwZgBGBt1fcQig=; b=LYibYPlTggb3i27Q26QDI/WATA0K6LuTQ4qe8urgYKz1AY26zHdSkS1PvalrlXcU0I ENCJY8wwrKxeualfR4iuB3Jd5L3Js72uBw5BKwuIAp7AHpMtrPeDTL1GyAgvIjMeJap1 29Ow77OD+TV97FsGIL55o++D/r7YGFBb0R7pQ= Received: by 10.42.157.68 with SMTP id c4mr9091391icx.4.1328926343186; Fri, 10 Feb 2012 18:12:23 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id uy10sm11783387igc.1.2012.02.10.18.12.18 (version=SSLv3 cipher=OTHER); Fri, 10 Feb 2012 18:12:19 -0800 (PST) From: "Kyle Hamilton" To: "Stephen Kent" Date: Fri, 10 Feb 2012 18:12:19 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgyi0fji5e0q4cuhcdc2 Cc: Joe St Sauver , "therightkey@ietf.org" , DIEGO LOPEZ GARCIA Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 02:12:24 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgyi0fji5e0q4cuhcdc2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=utf-8 DQpPbiBUaHUsIEZlYiA5LCAyMDEyIGF0IDM6MDUgUE0sIFN0ZXBoZW4gS2VudCA8a2VudEBiYm4u Y29tPiB3cm90ZToNCj4gQXQgMTE6MjkgUE0gKzAxMDAgMi85LzEyLCBESUVHTyBMT1BFWiBHQVJD SUEgd3JvdGU6DQo+PiDCoD4uLi5hbmQgSSBkbyBhZ3JlZSB3aXRoIHlvdSBpbiB0aGF0IHdoaWNo ZXZlciBlbnRpdHkgbWFraW5nIHN1Y2gNCj4+IGFzc2VydGlvbiAoWC41MDksIFNBTUwsIEpXVMWg KSBoYXMgdG8gYmUgYXV0aG9yaXRhdGl2ZSBmb3IgdGhlIGlkZW50aXR5DQo+PiBhc3NlcnRlZCBp ZiB5b3Ugd2FudCBpdCB0byBiZSB1c2FibGUuDQo+IEkgdGhpbmsgd2UgYXJlIGluIGFncmVlbWVu dC4gQ0FzIHRoYXQgYXJlIG5vdCBhdXRob3JpdGF0aXZlIGZvciBhc3NlcnRlZA0KPiBpZGVudGl0 aWVzIGFyZSBhcyBiYWQgYXMgZmVkZXJhdGVkIHRydXN0IGVudGl0aWVzIHdpdGggc2ltaWxhciBw cm9wZXJ0aWVzLg0KDQpXaGF0IGFyZSB0aGVzZSAnaWRlbnRpdGllcycgdGhhdCBuZWVkIHRvIGJl IGFzc2VydGVkIHdpdGggYXV0aG9yaXRhdGl2ZSBiYWNraW5nPyAgSSBob3BlIHlvdSdyZSBub3Qg anVzdCB0YWxraW5nIGFib3V0IHN0YXRlIGlkZW50aXRpZXMsIGV2ZW4gdGhvdWdoIHN0YXRlIGlk ZW50aXR5IGlzIGFuIGltcG9ydGFudCBwYXJ0IG9mIGl0LiAgVGhlIGN1cnJlbnQgY3JvcCBvZiBh dXRob3JpdGF0aXZlIGluZm9ybWF0aW9uIENBcyBhcmUgdmVyeSBnb29kIGF0IHR3byB0aGluZ3M6 IHRoZXkga25vdyBob3cgdG8gYXV0aGVudGljYXRlIGRvY3VtZW50cywgYW5kIHRoZXkga25vdyBo b3cgdG8gYXV0aGVudGljYXRlIGF1dGhvcml0eSAoZGVmaW5lZCBhcyAnYSBzdGF0ZScsIG9yICd0 aGUgZ292ZXJubWVudCBvZiBhIHN0YXRlJykuICBUaGV5IGFyZSBwcm9iYWJseSwgaW4gdGhhdCBy ZXNwZWN0LCBldmVuIGJldHRlciB0aGFuIFN0YXRlIERlcGFydG1lbnQgZW1wbG95ZWVzLg0KDQpV UyBGZWRlcmFsIGRvbid0IHdhbnQgdG8gZ2V0IGludm9sdmVkIHdpdGggcHJvdmlkaW5nIGEgc2Vy dmljZSB0byBldmVyeSBjaXRpemVuLiAgVGhleSB3b3VsZCByYXRoZXIgZm9zdGVyIHRoZSBkZXZl bG9wbWVudCBvZiBhIHByaXZhdGUgYXV0aGVudGljYXRpb24gc2VydmljZSBpbmR1c3RyeSwgYW5k IGFjY3JlZGl0IGl0LiAgTm8gbWF0dGVyIHdoYXQgd2UgbWlnaHQgYmVsaWV2ZSBpcyAiY29ycmVj dCIgZnJvbSBhIHB1cmVseSB0aGVvcmV0aWNhbCB2aWV3LCBVUyBGZWRlcmFsIEJyaWRnZSBQS0kg aGFzIGNyb3NzLWNlcnRpZmllZCBWZXJpc2lnbiwgVmVyaXpvbi9DeWJlcnRydXN0LCBPcGVyYXRp b25hbCBSZXNlYXJjaCBDb25zdWx0YW50cyBJbmMsIGFuZCBFbnRydXN0LiAgT24gdG9wIG9mIHRo aXMsIGFlcm9zcGFjZSBjb250cmFjdG9ycyBvZnRlbiBoYXZlIHRoZWlyIG93biBjZXJ0aWZpZXJz LCB3aG8gYXJlIGRlbGVnYXRlZCBzaW1pbGFyIEF1dGhvcml0eS4gIElyb25pY2FsbHksIHRoaXMg QXV0aG9yaXR5IGlzIGN1cnJlbnRseSBub3QgcmVjb2duaXplZCBieSB1c2VyIHNvZnR3YXJlLg0K DQpCdXQgdGhlIHJlYXNvbiB3aHkgSSBkb24ndCB3YW50IHRvIGdldCBodW5nIHVwIG9uIHN0YXRl IGlkZW50aXRpZXMgaXMgYmVjYXVzZSBjbHVicyBuZWVkIHRvIGhhdmUgdGhlaXIgb3duIGlkZW50 aXRpZXMsIHRvby4gIFZpcnR1YWwgY2x1YnMgYW5kIGZvcnVtcyBuZWVkIHRvIGhhdmUgdGhlaXJz IHRvbywgYW5kIGl0J3MgY29tbW9uIHByYWN0aWNlIHRvIGZpbGwgb3V0IGZvcnVtIHNpZ251cCBm b3JtcyB3aXRoIGJvZ3VzIGluZm9ybWF0aW9uIGJlY2F1c2UgdGhlIGZvcnVtcyB0eXBpY2FsbHkg ZG9uJ3QgYWN0dWFsbHkgbmVlZCByZWFsIGlkZW50aXR5IGluZm9ybWF0aW9uLiAgVHJ5aW5nIHRv IGluc2lzdCB0aGF0IHRoZSBETiBiZSBtYXRjaGVkIHNvbGVseSBmcm9tIGFuIGF1dGhvcml0YXRp dmUgQ0EgdmlvbGF0ZXMgdGhpcyAicHJpbmNpcGxlIG9mIGxlYXN0IHByaXZpbGVnZSIsIHdoaWNo IG1lYW5zIHRoYXQgcGVvcGxlIGNhbid0IHVzZSBhdXRob3JpdGF0aXZlIENBcyBpZiB0aGV5IHdh bnQgdG8gcHJvdGVjdCB0aGVpciBwZXJzb25hbCBpbmZvcm1hdGlvbiBmcm9tIGlkZW50aXR5IHRo aWV2ZXMgYW5kIHN0aWxsIGNvbW11bmljYXRlIG92ZXIgdGhlIG5ldHdvcmsuDQoNCi1LeWxlIEgN Cg== --gmsm1.9.5eqgyi0fji5e0q4cuhcdc2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTEwMjEyMjBaMCMGCSqGSIb3DQEJBDEWBBR5ybq5UK2ai8XZbo9xW6JF kRixojBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAND4V7jGAmaOqSmwzU2II7I9jE0XZQWj5G4aa5VwouFRa7C2elrErZ0L6CzRO3FAHRBYd sCzXvu/+4oOxSM0lOSku38vfeM1hAx8x2iI3PVqu0/iw4OcfAiFaOduAjgLMSdTY+0ZFPgb3grmQ V4LuoNI5Fhy91hz6etPnbo1hFn51YJPqY7kiXtoSANlpG+PStoLie9/VwAt020kUQDRXZ7R2EJXv cWsJgSQmIa4ImFpoX+VC7GCAstO4/grW+hLyiGPDcyL2CfGdgGbcsL53w73/uO981WoAjLI+k0ws PHMkyhK+1pSAhF/7B9gypmoT8igy2ufPFn9uKrJGD1iNsQAAAAAAAA== --gmsm1.9.5eqgyi0fji5e0q4cuhcdc2-- From eburger@standardstrack.com Sat Feb 11 06:50:54 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C896721F850D for ; Sat, 11 Feb 2012 06:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.481 X-Spam-Level: X-Spam-Status: No, score=-101.481 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR+FiX0hOH7a for ; Sat, 11 Feb 2012 06:50:53 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 2B02021F850F for ; Sat, 11 Feb 2012 06:50:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=sjxDpXJOz6b26peacheN8wP878YtVDeDDvMoW5FCx1oZC/GF6zfHszcvSJWwwwYEJ0OhEbe4kT7wEN4T8RG5YMvvEvklYzsiMx9rX/2WmMALndar/CoVx41nDWc0sWA5; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:62946 helo=[192.168.15.135]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RwEHr-00005v-PL for therightkey@ietf.org; Sat, 11 Feb 2012 06:50:52 -0800 From: Eric Burger Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-17-624814024; protocol="application/pkcs7-signature"; micalg=sha1 Date: Sat, 11 Feb 2012 09:50:48 -0500 In-Reply-To: <4F314AD2.3030905@KingsMountain.com> To: therightkey@ietf.org References: <4F314AD2.3030905@KingsMountain.com> Message-Id: X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [therightkey] Paris too soon for a meeting... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 14:50:54 -0000 --Apple-Mail-17-624814024 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would offer that I agree with Stephen that it is too soon for a work = group forming BOF. However, I would also offer that given the list = traffic, we have more than enough for a high-bandwidth discussion. I = would be up for a bar BOF or, if it makes more sense, a workshop outside = the constraints of the more-than-packed IETF week. On Feb 7, 2012, at 11:01 AM, =3DJeffH wrote: > Excellent summary Steve, thanks. >=20 > I'm up for a bar-BoF/side-meeting in Paris. >=20 >=20 > > There are specific (if not that well documented) > > proposals out there and I'd love to see their proponents > > arguing their relative merits in detail so's we > > could see if there are things that the IETF could/should > > be doing. >=20 > Agreed. I think that those folks having not spoken up or dived into = this discussion is telling wrt how early all this is. AFAIK there will = be some in-the-wild experiments run by various folk and that should = further inform discussions such as this. >=20 > =3DJeffH >=20 > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --Apple-Mail-17-624814024 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMjExMTQ1MDQ4WjAjBgkqhkiG9w0BCQQxFgQU vIy2upfczQdnsoJnQMFOXM7xRikwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAVEaSICbuVGUfGAVyrMnx6b8/6xZGDOJImI/bYUVQipLMuxnELjyE juciXdzj5PVPpZbcFnp6v1PkspJ0ZfB5ZV+vTrvsd5iVObJ5d8CUYT39zJ2Eke/Uqu3+hMaFi2Od lXxlqEL5iq6cEg6bcJUhDGqa8WW+W/ldJ58IP+zd6lCQ37b61YyMkAACyR43V52RpoPusGZwDZmr tVsRr2Nv1O/J5AQbtkGo9pWvpNPgK0vHvm0Jmdzl9mF6vF7UxG9N5OYJ7hD+tsYMQIeRq19g9y2g X2JI38VEw5MqDRrVQfYAAgql4/guTDiB20WPRuo9h/H3ZsS2a+x56Lsd4uvsRgAAAAAAAA== --Apple-Mail-17-624814024-- From kaie@kuix.de Sat Feb 11 07:53:04 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948BB21F84DC for ; Sat, 11 Feb 2012 07:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KxNVngHpUEL for ; Sat, 11 Feb 2012 07:53:04 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [82.165.38.173]) by ietfa.amsl.com (Postfix) with ESMTP id F3F1121F84D4 for ; Sat, 11 Feb 2012 07:53:03 -0800 (PST) Received: from [192.168.2.253] (p4FF3582B.dip.t-dialin.net [79.243.88.43]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id 79E0240015D2; Sat, 11 Feb 2012 16:53:02 +0100 (CET) Message-ID: <4F368EDE.3050501@kuix.de> Date: Sat, 11 Feb 2012 16:53:02 +0100 From: Kai Engert User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: therightkey@ietf.org References: <4F314AD2.3030905@KingsMountain.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Harry Halpin Subject: Re: [therightkey] Paris too soon for a meeting... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 15:53:04 -0000 If you decided to meet outside of the main IETF event, then I'd be able to join you. If the bar-BOF would either take place from 6 pm on March 29, or anytime on March 30/31, then I'd be able to join you. Best Regards Kai From stephen.farrell@cs.tcd.ie Sat Feb 11 16:57:28 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D130D21F848B for ; Sat, 11 Feb 2012 16:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMxbZfUOTDJT for ; Sat, 11 Feb 2012 16:57:27 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8546721F8486 for ; Sat, 11 Feb 2012 16:57:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7C38F171C2F; Sun, 12 Feb 2012 00:57:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1329008245; bh=6CFvZ+/J/gidQB zagF4c3B3LpF+8XiXRRuBjjnp0lCs=; b=5ltPjULewiyDagxHf3XvIQI5AW4CUy 41yUslnUU0kuWdqpw0r258Kiu9GsRX8Pf90OKEr+ZNlMAp6oDkp9gLkKP1DIGWbS GK/iaJV0gDoBL3W/RJtXsloWb0+NNZZlDPIEAJ5daeILX5QvPbWlyzE+fZJDFO9D HhX9hYt/7A9ZPsbNOq6e/kWioIIFyxNc/hrmAcAJzPcAGaZXFnTVoQ6TWxqOG3a4 DgnOv1DJd1BhSrc/rhI44+ggDVcVJNo8JWhVMwIiS0sHMQj8/rDbLhKZz83zD/aX NGorgA5Derb9alDsjzSJIDWIr2Wzcsj4Dojx9Jd2ZNi/oDR3ryZ9gpjg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id coIKS0vgN6Bb; Sun, 12 Feb 2012 00:57:25 +0000 (GMT) Received: from [10.87.48.6] (unknown [86.44.75.177]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5A0A2171C3E; Sun, 12 Feb 2012 00:57:23 +0000 (GMT) Message-ID: <4F370E72.9010601@cs.tcd.ie> Date: Sun, 12 Feb 2012 00:57:22 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Kai Engert References: <4F314AD2.3030905@KingsMountain.com> <4F368EDE.3050501@kuix.de> In-Reply-To: <4F368EDE.3050501@kuix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org, Harry Halpin Subject: Re: [therightkey] Paris too soon for a meeting... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 00:57:29 -0000 If folks wanna meet during IETF week then I'd suggest a doodle poll to pick a time slot. The someone can find a bar. If you get really boring and want a meeting room I can probably arrange that, but offer no guarantees about any particular time slot. (In any case a smallish group in a bar is better than 50 in a room ppt-gazing, really:-) S On 02/11/2012 03:53 PM, Kai Engert wrote: > If you decided to meet outside of the main IETF event, then I'd be able > to join you. > > If the bar-BOF would either take place from 6 pm on March 29, or anytime > on March 30/31, then I'd be able to join you. > > Best Regards > Kai > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From kaie@kuix.de Sun Feb 12 12:19:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5401721F8659 for ; Sun, 12 Feb 2012 12:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sylNxzLL7RUv for ; Sun, 12 Feb 2012 12:19:06 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [82.165.38.173]) by ietfa.amsl.com (Postfix) with ESMTP id C969B21F864E for ; Sun, 12 Feb 2012 12:19:04 -0800 (PST) Received: from [192.168.2.253] (p4FF34D6E.dip.t-dialin.net [79.243.77.110]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id B48694005144; Sun, 12 Feb 2012 21:19:03 +0100 (CET) Message-ID: <4F381EB7.8060306@kuix.de> Date: Sun, 12 Feb 2012 21:19:03 +0100 From: Kai Engert User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Stephen Farrell References: <4F314AD2.3030905@KingsMountain.com> <4F368EDE.3050501@kuix.de> <4F370E72.9010601@cs.tcd.ie> In-Reply-To: <4F370E72.9010601@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org, Harry Halpin Subject: Re: [therightkey] Paris too soon for a meeting... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 20:19:07 -0000 On 12.02.2012 01:57, Stephen Farrell wrote: > If folks wanna meet during IETF week then I'd suggest a doodle > poll to pick a time slot. How about this? http://www.doodle.com/8c5s43ayqbrft5rm Kai From ynir@checkpoint.com Sun Feb 12 12:40:56 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1BC21F865F for ; Sun, 12 Feb 2012 12:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8lSo9lsduLM for ; Sun, 12 Feb 2012 12:40:55 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D07BD21F8655 for ; Sun, 12 Feb 2012 12:40:54 -0800 (PST) X-CheckPoint: {4F382012-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q1CKeogm017388; Sun, 12 Feb 2012 22:40:50 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 12 Feb 2012 22:40:49 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sun, 12 Feb 2012 22:40:48 +0200 From: Yoav Nir To: Kai Engert Date: Sun, 12 Feb 2012 22:40:54 +0200 Thread-Topic: [therightkey] Paris too soon for a meeting... Thread-Index: AczpxpnBAT4mdtdTR+GyiCjQeUVf/A== Message-ID: References: <4F314AD2.3030905@KingsMountain.com> <4F368EDE.3050501@kuix.de> <4F370E72.9010601@cs.tcd.ie> <4F381EB7.8060306@kuix.de> In-Reply-To: <4F381EB7.8060306@kuix.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "therightkey@ietf.org" , Harry Halpin , Stephen Farrell Subject: Re: [therightkey] Paris too soon for a meeting... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 20:40:56 -0000 On Feb 12, 2012, at 10:19 PM, Kai Engert wrote: > On 12.02.2012 01:57, Stephen Farrell wrote: >> If folks wanna meet during IETF week then I'd suggest a doodle >> poll to pick a time slot. >=20 > How about this? > http://www.doodle.com/8c5s43ayqbrft5rm That's about it, but usually we do this after the preliminary agenda has be= en posted. Also, Friday after 18:00 is a non-starter.= From kaie@kuix.de Sun Feb 12 14:30:53 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2141D21F86D1 for ; Sun, 12 Feb 2012 14:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BmmpCch2Rjf for ; Sun, 12 Feb 2012 14:30:52 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [82.165.38.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4508321F86D0 for ; Sun, 12 Feb 2012 14:30:52 -0800 (PST) Received: from [192.168.2.253] (p4FF34D6E.dip.t-dialin.net [79.243.77.110]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id 613D54005156 for ; Sun, 12 Feb 2012 23:30:51 +0100 (CET) Message-ID: <4F383D98.7040505@kuix.de> Date: Sun, 12 Feb 2012 23:30:48 +0100 From: Kai Engert User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <4F314AD2.3030905@KingsMountain.com> <4F368EDE.3050501@kuix.de> <4F370E72.9010601@cs.tcd.ie> <4F381EB7.8060306@kuix.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] Paris too soon for a meeting... X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 22:30:53 -0000 On 12.02.2012 21:40, Yoav Nir wrote: > On Feb 12, 2012, at 10:19 PM, Kai Engert wrote: >> How about this? >> http://www.doodle.com/8c5s43ayqbrft5rm > That's about it, but usually we do this after the preliminary agenda has been posted. I have no eperience with IETF BoF meetings, so I apologize if my proposals don't match the expectations for agenda items. However, in order to get started, here are some questions that we could discuss. (a) Can we incrementally improve today's PKI trust model, or is a complete replacement necessary? (b) We heard proposals that require that all trust assertions (certificates) are made public, thereby creating public records of all certified entities. Is such a requirement acceptable? If not, is parallel deployment of public and private trust logs possible? (c) We heard proposals that domain owners shall be required to protect themselves from hijacking by permanently watching public logs for fraudulent actions. Is this requirement realistic and acceptable? (d) Consider the scenario "attacker controls all routes from hijacked server" and can thereby manipulate validation of domain ownership. Is this a problem a new/improved trust model should/can solve, or should this rather be solved at an organizational level, using out-of-band communication between assurer, registry and domain owner? (e) Make assessments for each of the proposed solutions, how close is each of them to a complete protocol specification? (f) Can we create a trust system that makes it completely impossible to create false trust assertions, or is quick detection of false trust assertions the best we can get? (g) Should better and quicker revocation of trust assertions be a mandatory, integral part of any new trust solutions, or are trust and revocation separate problems? > Also, Friday after 18:00 is a non-starter. I've removed the Friday-after-18 choice. Kai From diego@tid.es Sun Feb 12 16:06:48 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131AA21F8709 for ; Sun, 12 Feb 2012 16:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=-2.109, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ketvW4ZCIvN5 for ; Sun, 12 Feb 2012 16:06:47 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A79F21F8703 for ; Sun, 12 Feb 2012 16:06:44 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZB004TY1N60G@tid.hi.inet> for therightkey@ietf.org; Mon, 13 Feb 2012 01:06:43 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id C5.23.02893.214583F4; Mon, 13 Feb 2012 01:06:42 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LZB004TS1N60G@tid.hi.inet> for therightkey@ietf.org; Mon, 13 Feb 2012 01:06:42 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Mon, 13 Feb 2012 01:06:43 +0100 Date: Mon, 13 Feb 2012 01:06:41 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: Kyle Hamilton Message-id: <0E7EE1DF-58BB-4DEE-891D-71EB8A47FBCD@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [therightkey] Will the real RPF please stand up? Thread-index: Aczp411B7NEUZXZGTgSLXB0SnvInzQ== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f2d6d000000b4d-53-4f38541220b9 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsXCFe/ApSsUYuFv8OqlpcXHCz9ZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0XtsH3PBJ+GK+b/WMzYwbhDuYuTkkBAwkWg4eJodwhaTuHBv PVsXIxeHkMAGRomjN/tYIZx/jBL9F78yQjiNjBLT/35nBGlhEVCV2H7oNzOIzSagLtFy9BsL iC0sYCvxes8nVhCbU8BBYk/XGbAVIgJqEic/dAHVcHAwC1RItK7jAgnzClhKbF0/jx3CFpT4 MfkeVIm6xJQpuSBhZgFxiebWmywQtqLEtEUNYBcwAh39/dQaJojpdhKTH7xhg7D1JGZtncUK USMqcad9PSPEkwISS/acZ4awRSVePv4HViMk0MEoMXlCygRG8VlIrpiFcMUsJFfMQnLFAkaW VYxixUlFmekZJbmJmTnpBoZ6GZl6mXmpJZsYITGUsYNx+U6VQ4wCHIxKPLwr2k39hVgTy4or cw8xSnIwKYny7vS38BfiS8pPqcxILM6ILyrNSS0+xCjBwawkwis73dxfiDclsbIqtSgfJiXD waEkwdsYDNQmWJSanlqRlpkDTBQwaSYOTpB2HqD2iSA1vMUFibnFmekQ+VOMklLivEkgCQGQ REZpHlzvK0ZxoCOFeXNAsjzAlAbX9QpoIBPQQOlzJiADSxIRUlINjNOOymrqyFlM1055vSZM 6g/f4oqlrsJyrt75kzbs2cjN/pBzomvY/df7pvwOXGpxu3F/dlL0tzj7F0uXabiwGtcqnXx9 xK4sZ5Ko/Np9nCr7ot3Wz6s2Zq+b2HWNOS5lZ7/E0Zdu1yxntOrl2rHvVzmuvrTs2LdzVey8 CSZZ8r8yQxqWBHZ+UmIpzkg01GIuKk4EAC67+dwmAwAA References: Cc: Joe St Sauver , "therightkey@ietf.org" , Stephen Kent Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 00:06:48 -0000 DQpPbiAxMSBGZWIgMjAxMiwgYXQgMDM6MTIgLCBLeWxlIEhhbWlsdG9uIHdyb3RlOg0KPiBXaGF0 IGFyZSB0aGVzZSAnaWRlbnRpdGllcycgdGhhdCBuZWVkIHRvIGJlIGFzc2VydGVkIHdpdGggYXV0 aG9yaXRhdGl2ZSBiYWNraW5nPyAgSSBob3BlIHlvdSdyZSBub3QganVzdCB0YWxraW5nIGFib3V0 IHN0YXRlIGlkZW50aXRpZXMsIGV2ZW4gdGhvdWdoIHN0YXRlIGlkZW50aXR5IGlzIGFuIGltcG9y dGFudCBwYXJ0IG9mIGl0LiAgVGhlIGN1cnJlbnQgY3JvcCBvZiBhdXRob3JpdGF0aXZlIGluZm9y bWF0aW9uIENBcyBhcmUgdmVyeSBnb29kIGF0IHR3byB0aGluZ3M6IHRoZXkga25vdyBob3cgdG8g YXV0aGVudGljYXRlIGRvY3VtZW50cywgYW5kIHRoZXkga25vdyBob3cgdG8gYXV0aGVudGljYXRl IGF1dGhvcml0eSAoZGVmaW5lZCBhcyAnYSBzdGF0ZScsIG9yICd0aGUgZ292ZXJubWVudCBvZiBh IHN0YXRlJykuICBUaGV5IGFyZSBwcm9iYWJseSwgaW4gdGhhdCByZXNwZWN0LCBldmVuIGJldHRl ciB0aGFuIFN0YXRlIERlcGFydG1lbnQgZW1wbG95ZWVzLg0KDQpBdXRob3JpdGF0aXZlIGluIHRl cm1zIHRoYXQgdGhleSBhcmUgdGhlIHJlY29nbml6ZWQgc291cmNlIGZvciB3aGF0ZXZlciBpZGVu dGl0eSBkYXRhIGFzc2VydGVkLiBBcyBTdGV2ZSBhbHJlYWR5IHNhaWQgaW4gdGhpcyBzYW1lIHRo cmVhZDoNCg0KT24gMTAgRmViIDIwMTIsIGF0IDAxOjIyICwgU3RlcGhlbiBLZW50IHdyb3RlOg0K PiBBIENBIG9wZXJhdGVkIGJ5IGEgY29tcGFueSBpcyB0aGUgcmlnaHQgQ0EgdG8gaWRlbnRpdHkg aW5kaXZpZHVhbHMgYXMNCj4gZW1wbG95ZWVzIG9mIHRoYXQgY29tcGFueS4gaWYgdGhlIGNvbXBh bnkgb3BlcmF0ZXMgaXQncyBkb21haW4gYW5kDQo+IG1hbmFnZXMgbWFpbGJveGVzIGZvciBpdHMg ZW1wbG95ZWVzIGluIHRoYXQgZG9tYWluLCB0aGVuIGl0IGlzIGhlDQo+IHJpZ2h0IENBIHRvIGlz c3VlIGNlcnRzIHdpdGggZW1wbG95ZWUgZS1tYWlsIGFkZHJlc3Nlcy4NCg0KDQpJZiB3ZSBhcmUg dGFsa2luZyBhYm91dCBpZGVudGl0eSBkYXRhIHJlbGF0ZWQgdG8gY2l0aXplbnNoaXAsIHRoZW4g d2UnbGwgbmVlZCBzdGF0ZSBhdXRob3JpdGllcy4gT3RoZXJ3aXNlLCB0aGUgYXBwcm9wcmlhdGUg c291cmNlIHNoYWxsIGJlIHVzZWQ6IGEgY29tcGFueSBmb3IgaXRzIGVtcGxveWVlcywgYSB1bml2 ZXJzaXR5IGZvciBpdHMgc3R1ZGVudHMgb3IgZmFjdWx0eSwgYW5kIGFuIGFzc29jaWF0aW9uIGZv ciBpdHMgbWVtYmVycy4uLg0KDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9y IEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9w ZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAg ICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2Ug ZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJh IHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28g ZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRl ZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZl IGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdA0KaHR0cDovL3d3dy50 aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== From nico@cryptonector.com Sun Feb 12 17:39:32 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC3921F86F1 for ; Sun, 12 Feb 2012 17:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.622 X-Spam-Level: X-Spam-Status: No, score=-0.622 tagged_above=-999 required=5 tests=[AWL=-1.245, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ScS-DS4nCdn for ; Sun, 12 Feb 2012 17:39:31 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF2621F8677 for ; Sun, 12 Feb 2012 17:39:31 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 59E491DE00B for ; Sun, 12 Feb 2012 17:39:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=PpXGLZWdVSq3mPAyESXth1lU22t14keJHEbSHNRpqrRC bwt0Y8xXtdG5zs3Wh1hbF0n6SqhsexEAZEhwPH9GXa3TY4GWU59Wk6H2fG70mIP1 svUeyTuvvR419LLwR3b8DUGKwqJQ3ZYHF12unfzIhReL60gtqHhR2IFGf/OaDEU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=Jzd1HNj7Hr5qnrkr8Iog0XCvFOI=; b=QIZNVTEkt7p 5eJodPW2Ft6jG75WJ+ROnRlTAoKVosfr7zfwBaEtBs63auQjoMkHi0xUNN1MOQ0x kK+KvzpYiCMblkpAivWfMQXn/EsCf4MfJVD0vrl5QbrnryH/woO2412S6P8l00NB xqH+XhzMA2mbwokqEFU6XmIU+tjGmIIQ= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 472781DE005 for ; Sun, 12 Feb 2012 17:39:31 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so4331054pbc.31 for ; Sun, 12 Feb 2012 17:39:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.217.67 with SMTP id ow3mr41704137pbc.125.1329097170709; Sun, 12 Feb 2012 17:39:30 -0800 (PST) Received: by 10.68.136.4 with HTTP; Sun, 12 Feb 2012 17:39:30 -0800 (PST) Date: Sun, 12 Feb 2012 19:39:30 -0600 Message-ID: From: Nico Williams To: therightkey@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 01:39:32 -0000 Whether we pursue auditable CAs / notaries, Convergence, HSTS, user authentication that can do channel binding -- all these options are about keeping the CAs honest by making it too likely that MITMing CAs (whether compromised or by business plan) will get detected. Someone made a comment about elegance. I'm not sure that anything other than making CAs auditable is elegant, but I don't think elegance is really what we're after (though elegance is always nice). I think we're after a PKI where MITMing is not likely to pay off except in relatively rare circumstances (e.g., when a new device is bootstrapping itself), so rare that it isn't worth trying to MITM even in those very few cases. That would make me like PKI. Nico -- From mrex@sap.com Mon Feb 13 08:36:48 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB23C21F8704 for ; Mon, 13 Feb 2012 08:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.114 X-Spam-Level: X-Spam-Status: No, score=-10.114 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eiDcwRwv9Zm for ; Mon, 13 Feb 2012 08:36:48 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C15A521F86DD for ; Mon, 13 Feb 2012 08:36:47 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1DGagi8017297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Feb 2012 17:36:42 +0100 (MET) From: Martin Rex Message-Id: <201202131636.q1DGafVR006049@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Mon, 13 Feb 2012 17:36:41 +0100 (MET) In-Reply-To: from "Nico Williams" at Feb 12, 12 07:39:30 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: therightkey@ietf.org Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 16:36:48 -0000 Nico Williams wrote: > > Whether we pursue auditable CAs / notaries, Convergence, HSTS, user > authentication that can do channel binding -- all these options are > about keeping the CAs honest by making it too likely that MITMing CAs > (whether compromised or by business plan) will get detected. Someone > made a comment about elegance. I'm not sure that anything other than > making CAs auditable is elegant, but I don't think elegance is really > what we're after (though elegance is always nice). I think we're > after a PKI where MITMing is not likely to pay off except in > relatively rare circumstances (e.g., when a new device is > bootstrapping itself), so rare that it isn't worth trying to MITM even > in those very few cases. The fact that there are products (client-side HTTPS proxies that perform MITM and inspect content) actively sold and used, which are vitally dependent on being able to exploit weaknesses of the existing TLS X.509 PKI security&trust model, is a sure proof that something is wrong with the existing security model. I do not think there is value in maintaining backward compatible weaknesses, and personally, I do not mind the slightest about breaking those protocol subverting middle boxes, be it by the use of TLS channel bindings, or the checking of DANE TLSA records. -Martin From drc@virtualized.org Mon Feb 13 10:21:54 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DDF21F8758 for ; Mon, 13 Feb 2012 10:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWfBbgpCRO7z for ; Mon, 13 Feb 2012 10:21:51 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1B10F21F8755 for ; Mon, 13 Feb 2012 10:21:38 -0800 (PST) Received: from [192.168.2.159] (unknown [173.245.57.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 98A421705A; Mon, 13 Feb 2012 18:21:36 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <201202131636.q1DGafVR006049@fs4113.wdf.sap.corp> Date: Mon, 13 Feb 2012 10:21:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0600CF7A-A8CB-4E35-B729-43D626434645@virtualized.org> References: <201202131636.q1DGafVR006049@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) Cc: therightkey@ietf.org Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 18:21:54 -0000 On Feb 13, 2012, at 8:36 AM, Martin Rex wrote: > The fact that there are products (client-side HTTPS proxies that > perform MITM and inspect content) actively sold and used, > which are vitally dependent on being able to exploit weaknesses > of the existing TLS X.509 PKI security&trust model, is a sure proof > that something is wrong with the existing security model. Well, it is proof that the theoretical model in which authorized MITM = was disallowed was seen as too limiting.=20 > I do not think there is value in maintaining backward compatible > weaknesses, and personally, I do not mind the slightest about breaking=20= > those protocol subverting middle boxes, be it by the use of TLS = channel > bindings, or the checking of DANE TLSA records. Pragmatically speaking, if you come up with an architecture that = disallows people from doing what they want/need to do, they'll either = figure out ways around it or not use that architecture.=20 Regards, -drc From hallam@gmail.com Mon Feb 13 10:32:50 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7E221F8550 for ; Mon, 13 Feb 2012 10:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIrUEgYTE32m for ; Mon, 13 Feb 2012 10:32:49 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6DC21F8559 for ; Mon, 13 Feb 2012 10:32:49 -0800 (PST) Received: by ggnq2 with SMTP id q2so2931181ggn.31 for ; Mon, 13 Feb 2012 10:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5/SYBm3Q3tC2FqXtQIRjx5GN/zunAoXCzxyymg1c7V8=; b=MKLODMB7yv5TVWkEQafHRkmttYH66E6rkPlBUZ3TRHoAh/HivBIUN5Cjind0v91H/B 6fDS6DjIif1/AqOZfqz9NUH+I/CYJL9caUMcBhXgS4cCqdEuy51H4vxgEPC5C+1DKIWg IN0wHDjOfw7uCs68pQcZrlUX1JRNAyKmhexuU= MIME-Version: 1.0 Received: by 10.60.19.73 with SMTP id c9mr4920908oee.19.1329157969036; Mon, 13 Feb 2012 10:32:49 -0800 (PST) Received: by 10.182.75.138 with HTTP; Mon, 13 Feb 2012 10:32:48 -0800 (PST) In-Reply-To: <0600CF7A-A8CB-4E35-B729-43D626434645@virtualized.org> References: <201202131636.q1DGafVR006049@fs4113.wdf.sap.corp> <0600CF7A-A8CB-4E35-B729-43D626434645@virtualized.org> Date: Mon, 13 Feb 2012 13:32:48 -0500 Message-ID: From: Phillip Hallam-Baker To: David Conrad Content-Type: text/plain; charset=ISO-8859-1 Cc: therightkey@ietf.org, mrex@sap.com Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 18:32:50 -0000 +1 It is also worth pointing out that the MITM certs stopped being offered commercially as soon as it became public knowledge that they had been. Presumably the next step the companies providing this facility will take is to offer their own browser with the capability built in. It is no good jumping up and down saying people should not make such devices. The choice we have is whether to do the job right or let them do it without any input. What I find wrong with the MITM proxies is that they offer a completely transparent mechanism. The user is not notified that they are being logged. I think that is a broken approach because the whole point of accountability controls is that people behave differently when they know they are being watched. I don't mean just changing the color of the address bar either. I would want to see something like the following: 0) The intercept capability is turned on in the browser, this would be done using a separate tool and lock the browser to a specific intercept cert root. 1) User attempts to connect to https://www.example.com 2) Browser throws up splash screen for 5secs stating 'Your connection has been intercepted' 3) Business as usual. The splash screen would appear once per session with a new host and reset periodically. It should show the interception cert being used as well. On Mon, Feb 13, 2012 at 1:21 PM, David Conrad wrote: > On Feb 13, 2012, at 8:36 AM, Martin Rex wrote: >> The fact that there are products (client-side HTTPS proxies that >> perform MITM and inspect content) actively sold and used, >> which are vitally dependent on being able to exploit weaknesses >> of the existing TLS X.509 PKI security&trust model, is a sure proof >> that something is wrong with the existing security model. > > Well, it is proof that the theoretical model in which authorized MITM was disallowed was seen as too limiting. > >> I do not think there is value in maintaining backward compatible >> weaknesses, and personally, I do not mind the slightest about breaking >> those protocol subverting middle boxes, be it by the use of TLS channel >> bindings, or the checking of DANE TLSA records. > > Pragmatically speaking, if you come up with an architecture that disallows people from doing what they want/need to do, they'll either figure out ways around it or not use that architecture. > > Regards, > -drc > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey -- Website: http://hallambaker.com/ From nico@cryptonector.com Mon Feb 13 10:42:05 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7D921F87D0 for ; Mon, 13 Feb 2012 10:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8yhJyvxNELZ for ; Mon, 13 Feb 2012 10:42:04 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id C4C8321F87CA for ; Mon, 13 Feb 2012 10:42:04 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 9174B1E076 for ; Mon, 13 Feb 2012 10:42:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=T+qXj5Q+a3JXEoBmoK4Cf hmT6xAhLjpEb0+LCIT75ohIKQR58+JXmw4rZpwUHDSK09GcheEOCkRl8b54TgRnd QCVcohRqqA89yDs+oMROsowO7nGvNfOuonhOOTyguAHF8VNzTVZdraeAtEA2xOz9 XWBZTOpVlaqS7aYSFm4XT4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=LfWlM/Qdg4sI07VtO7q4 YeFD0IY=; b=ObzHPxVFAljeGomLN3ksmBCk+NagG0EixDQ9CBpWSjr/FPEpGYiE o2hcyvEbwbFQOB3i6Io2pak5NGzP3WqStHKXPX5VlbYCAZ5QnPl6p/sj5dnySAYQ g9c49mM7AnUqWq0+arHthqUtsc16+FZergD62u3DonXZJz18V4NJOWY= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 7770A1E020 for ; Mon, 13 Feb 2012 10:42:04 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so5029581pbc.31 for ; Mon, 13 Feb 2012 10:42:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.232.103 with SMTP id tn7mr49766255pbc.74.1329158524070; Mon, 13 Feb 2012 10:42:04 -0800 (PST) Received: by 10.68.136.4 with HTTP; Mon, 13 Feb 2012 10:42:04 -0800 (PST) In-Reply-To: References: <201202131636.q1DGafVR006049@fs4113.wdf.sap.corp> <0600CF7A-A8CB-4E35-B729-43D626434645@virtualized.org> Date: Mon, 13 Feb 2012 12:42:04 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: therightkey@ietf.org, mrex@sap.com, David Conrad Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 18:42:05 -0000 On Mon, Feb 13, 2012 at 12:32 PM, Phillip Hallam-Baker wrote: > +1 > > It is also worth pointing out that the MITM certs stopped being > offered commercially as soon as it became public knowledge that they > had been. > > Presumably the next step the companies providing this facility will > take is to offer their own browser with the capability built in. It is > no good jumping up and down saying people should not make such > devices. The choice we have is whether to do the job right or let them > do it without any input. > > > What I find wrong with the MITM proxies is that they offer a > completely transparent mechanism. The user is not notified that they > are being logged. I think that is a broken approach because the whole > point of accountability controls is that people behave differently > when they know they are being watched. I'm confused: if this is wrong, and if preventing MITMing CAs leads to an MITM model that is right (because the users are informed), then why does it no good to jump up and down saying that people should not make MITM devices? It seems to me that it will have done plenty of good. The object for me is not to prevent MITMing when the user knows. I really don't care about corporate MITM devices because I assume users (employees, contractors) are informed. Like you I care about MITM devices that users *don't* know about. Not all spy-on-your-employees solutions are bad, thus the fact that alternatives will arise does not necessarily bother me. Only those that can be used against users who are not informed or have no way to avoid the MITM (employees can always... not use employer networks for personal use). Think of people in Iran, Syria, ... Nico -- From drc@virtualized.org Mon Feb 13 11:03:04 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C9521F8697 for ; Mon, 13 Feb 2012 11:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Pvu3qcM23eO for ; Mon, 13 Feb 2012 11:03:03 -0800 (PST) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id BF51821F8687 for ; Mon, 13 Feb 2012 11:03:03 -0800 (PST) Received: from [192.168.2.159] (unknown [173.245.57.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 457B21705A; Mon, 13 Feb 2012 19:03:03 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: Date: Mon, 13 Feb 2012 11:03:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201202131636.q1DGafVR006049@fs4113.wdf.sap.corp> <0600CF7A-A8CB-4E35-B729-43D626434645@virtualized.org> To: Nico Williams X-Mailer: Apple Mail (2.1257) Cc: therightkey@ietf.org Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:03:04 -0000 On Feb 13, 2012, at 10:42 AM, Nico Williams wrote: > Not all spy-on-your-employees solutions are bad, thus the fact that > alternatives will arise does not necessarily bother me. And they aren't all 'spy-on-your-employees'. For example, companies = such as CloudFlare (for whom I work), Incapsula, Torbit, etc., provide = various web security and performance-related services by acting as a = reverse proxy and scrubbing HTTP/HTTPS connections. These services tend = to be targeted at SMEs who are often less-than-technically-knowledable = web site operators and those website owners will reject any solution = that isn't transparent to their customers. While I can't speak for the = others, CloudFlare's service is not in any way a "spy-on-your-employees" = solution, rather it is a service in which website owners intentionally = insert a MITM that helps them deal with various attacks (DDoS, blog = spam, screen scrapers, etc). Regards, -drc From martin@millnert.se Mon Feb 13 11:08:10 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF4E21F8712 for ; Mon, 13 Feb 2012 11:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nObzrPjgi2J4 for ; Mon, 13 Feb 2012 11:08:09 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [95.80.1.101]) by ietfa.amsl.com (Postfix) with ESMTP id 76DD221F870F for ; Mon, 13 Feb 2012 11:08:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 2584872F; Mon, 13 Feb 2012 20:05:51 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO9lN+UrmdiP; Mon, 13 Feb 2012 20:05:50 +0100 (CET) Received: from [192.168.120.227] (h-189-4.a189.priv.bahnhof.se [85.24.189.4]) by ncis.csbnet.se (Postfix) with ESMTPSA id 646F2D9; Mon, 13 Feb 2012 20:05:49 +0100 (CET) Message-ID: <1329160081.11318.5.camel@davinci.millnert.se> From: Martin Millnert To: Nico Williams Date: Mon, 13 Feb 2012 20:08:01 +0100 In-Reply-To: References: <201202131636.q1DGafVR006049@fs4113.wdf.sap.corp> <0600CF7A-A8CB-4E35-B729-43D626434645@virtualized.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-p8ehAJ0yevezTE/3wvaP" X-Mailer: Evolution 3.0.3-3 Mime-Version: 1.0 Cc: therightkey@ietf.org, mrex@sap.com, Phillip Hallam-Baker , David Conrad Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:08:10 -0000 --=-p8ehAJ0yevezTE/3wvaP Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2012-02-13 at 12:42 -0600, Nico Williams wrote: > On Mon, Feb 13, 2012 at 12:32 PM, Phillip Hallam-Baker = wrote: > > Presumably the next step the companies providing this facility will > > take is to offer their own browser with the capability built in. It is > > no good jumping up and down saying people should not make such > > devices. The choice we have is whether to do the job right or let them > > do it without any input. > > > > > > What I find wrong with the MITM proxies is that they offer a > > completely transparent mechanism. The user is not notified that they > > are being logged. I think that is a broken approach because the whole > > point of accountability controls is that people behave differently > > when they know they are being watched. > Not all spy-on-your-employees solutions are bad, thus the fact that > alternatives will arise does not necessarily bother me. Only those > that can be used against users who are not informed or have no way to > avoid the MITM (employees can always... not use employer networks for > personal use). Think of people in Iran, Syria, ... With an ability to define how to interpret various security / trust sources/inputs at the host operating system level, this is an already solved issue. The managed corporate computer environment need only have a policy activated which trusts the MITM-CA, and modulo application implementations (including browsers), it is a matter of GUI/HMI how to display the SSL-connection to the MITM device versus other input sources, should they be active in the policy. If users can see they are using a more trusted environment at home then at their MITM:ing work place, all the better? /M --=-p8ehAJ0yevezTE/3wvaP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJPOV+RAAoJEKgraNdZrwxMLUQP/A1h3dMCwUIbCRbe/XvDgT5A o21Av9PdIzXQEd/aahRZjPn0l0pXR+WZHKUS5MgbkswIOvQUCEnxl5QR+whLT14X anCmJBXvZbU3tlrIdFlqN/eYelhHzvPBSZbexHqg9gTQnjXOQ/I9jl15zf8YEzv6 8tR0c09I0WhbnN4hBH3p6nlJZaofH/mjqx9kKPz5de+0i8OGqQ2iG/0ZXlW/RNa+ RMyuJOs98pp2KYcqmQeIEqcLSCZpqPFo6bH2YH7/nGkqjzpnNWxwdb2UmglztSfc +Ff0E/Y5XC09zVnqGRbatvHlthKKqgZF9KbhWqDGZ4PRvEwok0yDRsgq0VtBlEJX NRtMHRUF25ymC0+tmHQ2OG6Jj5lWWBQoNadUGyWKdA07UuFGCIwn7VJTYGb4OW68 j3S+m8vrlWNkL2j+NqaQqtTXsiV7QhJsn/Wu5fNcFdyb/DGuFafa+qLxdcPvnhm1 zjT/ZihWq2ZC9Ymcv3w8rYV22Lh2OQp4DUSA5Ze+yqh1OS2IuowYXFnuVd0xm5MX +dr1B5JjWkBnqhcKzllo6DCCZplacWOhCVeRMqKYJNNbrIpJCIt4Fh0stCLVUTCL 34CdtUNQoGcTnNQcGE9ZijOFBIGVuGMHn6QYNJGpuwAkd4dfjiJQmDib14zOiuP6 40693kcmkyrhk1s6n0uf =ajqJ -----END PGP SIGNATURE----- --=-p8ehAJ0yevezTE/3wvaP-- From martin@millnert.se Mon Feb 13 11:15:46 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2933321F86C7 for ; Mon, 13 Feb 2012 11:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8sYU+wYlWsZ for ; Mon, 13 Feb 2012 11:15:45 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [95.80.1.101]) by ietfa.amsl.com (Postfix) with ESMTP id 609F221F86D8 for ; Mon, 13 Feb 2012 11:15:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 40A8572F; Mon, 13 Feb 2012 20:13:27 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs33Vebg8L4t; Mon, 13 Feb 2012 20:13:27 +0100 (CET) Received: from [192.168.120.227] (h-189-4.a189.priv.bahnhof.se [85.24.189.4]) by ncis.csbnet.se (Postfix) with ESMTPSA id EB31BD9; Mon, 13 Feb 2012 20:13:26 +0100 (CET) Message-ID: <1329160539.11318.12.camel@davinci.millnert.se> From: Martin Millnert To: David Conrad Date: Mon, 13 Feb 2012 20:15:39 +0100 In-Reply-To: References: <201202131636.q1DGafVR006049@fs4113.wdf.sap.corp> <0600CF7A-A8CB-4E35-B729-43D626434645@virtualized.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-IuY5w4dmp8+SGiHFK1pU" X-Mailer: Evolution 3.0.3-3 Mime-Version: 1.0 Cc: Nico Williams , therightkey@ietf.org Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:15:46 -0000 --=-IuY5w4dmp8+SGiHFK1pU Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2012-02-13 at 11:03 -0800, David Conrad wrote: > On Feb 13, 2012, at 10:42 AM, Nico Williams wrote: > > Not all spy-on-your-employees solutions are bad, thus the fact that > > alternatives will arise does not necessarily bother me. >=20 > And they aren't all 'spy-on-your-employees'. For example, companies such= as CloudFlare (for whom I work), Incapsula, Torbit, etc., provide various = web security and performance-related services by acting as a reverse proxy = and scrubbing HTTP/HTTPS connections. These services tend to be targeted a= t SMEs who are often less-than-technically-knowledable web site operators a= nd those website owners will reject any solution that isn't transparent to = their customers. While I can't speak for the others, CloudFlare's service i= s not in any way a "spy-on-your-employees" solution, rather it is a service= in which website owners intentionally insert a MITM that helps them deal w= ith various attacks (DDoS, blog spam, screen scrapers, etc). >=20 Conrad, this seems slightly different than the spy-on-your-employees case though (close to server rather than client), in that the MITM web-frontend would just be able to publish the original web site's cert, or, another cert. To some degree client's can just consider the MITM machine to be the actual web server, and the actual web server to be the web-server backend, right? All the same the client-facing cert would be the cert observed by the notaries, for instance. /M --=-IuY5w4dmp8+SGiHFK1pU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJPOWFbAAoJEKgraNdZrwxMusEP/ilhjg1nrzMlxwWL/gMnOyqY I0+F0CwcbVwWcPtro4o5rtyxqaMh9q+2NhqfYjE8eqcpVfdX0ihFQih63hlDEMPx WDilJIW6lsRKfX62sEw/y9plsxO9qW46fdSte2h3tFhleV1uB3XBZ22QVWEVAtZq UUL+hgOcV8nWDoBxC3dCsPZs0OJtDL99MAV2NedRfRGJYuuNpMmPpFykuYEmxseW x6DQ7aJMJUdYWoYBEE9Sa557Mc4OGuSKzijFKRrEPDt9PgoLmyvBwkyrcK1EuU39 ycCqG2M4YrTq4alXOU9cWIK8WB2cTE/nKJkzeABm8GPqBCTBDMj1t3dO3/5Bfbje EQHC8Vugh6PNJZikhHek1JkfCRD49PBr7ntileWhjXelyFwcZpfqsPY7EO8e90ci KFl2EIeQlvWdD39uZ6RKxn0lE/kCPzXn/f/U2Jqtz1zquKsBeqtxNhwKskPgXsv7 nmPpO5DNe+gApYwVt7JAK7nPMI4sC/Cwi4bq0OjUhWi2ux3gcBUcfKUe1M709drb xY4mA6a/VqdIATf8UaPoWWXNYKNhJ16QRwmQgfHVhY5x/Rlxe8BRV0uNu5HAnDnn bFDwMqfb/rwrxGmTjDEVZC3N1TbXkG+V8v/pwWt7iuHwER3eeanfXMb74J3/TpUk wUBkx8vUtan9vpGLh2e6 =RBKF -----END PGP SIGNATURE----- --=-IuY5w4dmp8+SGiHFK1pU-- From hallam@gmail.com Mon Feb 13 11:20:04 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26DD21F86A0 for ; Mon, 13 Feb 2012 11:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n63SavYXW13p for ; Mon, 13 Feb 2012 11:20:03 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA5121F869A for ; Mon, 13 Feb 2012 11:20:01 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8325673obb.31 for ; Mon, 13 Feb 2012 11:20:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=YeTu2NbeOn4piQislL5rtTUWrNZfzS/6XehqYxw13gs=; b=jde+HBjEAXvQDx4gxWUm2QJbT4cU3d7wFqhxf0/vi0kajdgaQrjCbCyrX2uZxKRJnJ 0GJTWFvLSzIjnXf5M3WJircywjeqNdx5MfbzHbJ5+M/am0bTdaSHui8vNRZsl2Qn//Fw jJ2/0NGMSdwTwANBkK2gehjBHXTVi2VDOR+58= MIME-Version: 1.0 Received: by 10.182.75.102 with SMTP id b6mr13193752obw.9.1329160801098; Mon, 13 Feb 2012 11:20:01 -0800 (PST) Received: by 10.182.75.138 with HTTP; Mon, 13 Feb 2012 11:20:01 -0800 (PST) Date: Mon, 13 Feb 2012 14:20:01 -0500 Message-ID: From: Phillip Hallam-Baker To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [therightkey] Starting on some drafts X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:20:04 -0000 I am starting to work on a suite of drafts to set out the architecture I described earlier in the pdf document. The starting point I am working from is the security policy draft Rob and I wrote earlier: http://tools.ietf.org/html/draft-hallambaker-securitypolicy-01 The idea of this draft was that it would serve the needs of static security policy distribution which is one of the modes of policy distribution we are going to need. I see a need for the following documents: 1) Security Policy Specification * Abstract security policy statements * Format for representing static security policy statements by trust brokers * Format for originating security policy as DNS headers * Format for originating security policy as application (i.e. HTTP) headers 2) Online broker protocol * Abstract protocol * Web Service REST binding * UDP REST binding * DNS binding 3) Architecture document In a bit more detail: 1) Security Policy Specification Having looked at this problem a lot I think we need to support more than one way to exchange security policy statements. In particular there is definitely a need to be able to originate security policy as application headers (e.g. WebSec pinning) and the DNS is clearly the proper infrastructure to originate authoritative statements about domain names. But merely originating security policy is not enough. First it is unlikely that there will be a great deal of security policy available to start with. Second, relying on administrator originated assertions is likely to give too many false positives to hardfail. So the scenario I think will prevail at the start is something like 5% or so of SSL web sites publish security policies through the DNS 20% or so publish security policies as application headers 90% or so of Web sites are stable enough for a low confidence security policy to be inferred by observation and heuristics One of the things we have learned from experience is that detecting and reporting security policy violations has greater benefit to the community of users than merely protecting individual users. So things like Convergence and CT and such add to what is provided by the EFF observatory alone, but the core value comes from detecting and reporting. The good news is that we can get detecting and reporting for 90% of the Web through the trust broker model without any adoption by Web sites. This is critical as far as deployment goes as it breaks the deployment deadlock cycle. There is an incentive for clients to deploy on day 1. As the number of deployed clients increases, there is an incentive for Web sites to originate policy assertions and guide the process. I see two modes for broker interactions. The first is a static hotlist of 'critical' security policies that the trust broker pushes out to the client. This would be used for ensuring policy enforcement in cases of actual attack. Some sites are attacked so frequently as to make the permanent hotlist. The second mode is an online protocol performed on a per IP connection basis and has rather different performance constraints and so needs to be considered separately. 2) Online broker protocol At present a HTTPS client typically performs the following interactions: 1) DNS lookup to resolve 'www.example.com' 2) Connect to port 443 on www.example.com 3) Start TLS session, acquire cert 4) DNS lookup to resolve ocsp.ca.com 5) OCSP request to ocsp.ca.com 6) WTF starts TLS session 7) OCSP response is received (too late) Adding in a call to a trust broker on top is a non starter. So any trust broker interaction has to replace either or both of the DNS and OSCP interactions. I suggest both. So the abstract protocol becomes 1) UDP request to trustbroker.com ? DNS-name + Port + Protocol *(+ options) UDP response : IPaddress + Port + SecurityOptions *(+ options) *(+ proof) 2) Client connects to specified IPaddress, port, etc. The proof might consist of: DNS RRs DNSSEC RRs Notary statements Certificates SAML assertions etc. How much proof a client requires would depend on the application and the user. Needs will differ. As a practical matter, there would be a need to use the protocol when the only ports available are 80, 443 and port 53 to the DNS resolver chosen by the ISP. So there would be a need to layer the protocol onto DNS. This would probably mean some sort of BASE32/64 encoding hack and TXT records. Trying to pass proof over that type of connection is probably a non-starter and so there would have to be a http/REST service as well. -- Website: http://hallambaker.com/ From mrex@sap.com Mon Feb 13 11:21:13 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223B021F86A0 for ; Mon, 13 Feb 2012 11:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.116 X-Spam-Level: X-Spam-Status: No, score=-10.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sLST-MCFmNE for ; Mon, 13 Feb 2012 11:21:12 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 68C0921F869A for ; Mon, 13 Feb 2012 11:21:10 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1DJL4HC007528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Feb 2012 20:21:04 +0100 (MET) From: Martin Rex Message-Id: <201202131921.q1DJL3Nm015737@fs4113.wdf.sap.corp> To: hallam@gmail.com (Phillip Hallam-Baker) Date: Mon, 13 Feb 2012 20:21:03 +0100 (MET) In-Reply-To: from "Phillip Hallam-Baker" at Feb 13, 12 01:32:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: therightkey@ietf.org, mrex@sap.com, drc@virtualized.org Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:21:13 -0000 Phillip Hallam-Baker wrote: > > What I find wrong with the MITM proxies is that they offer a > completely transparent mechanism. The user is not notified that they > are being logged. I think that is a broken approach because the whole > point of accountability controls is that people behave differently > when they know they are being watched. MITM proxies are bad in several ways. Not only that they're trying to hide (by faking server certs), they also breaking client-cert authentication, interfere with TLS channel bindings and will break other approaches that intend to fix the shortcomings of the Browser's TLS X.509 PKI trust model. -Martin From hallam@gmail.com Mon Feb 13 11:26:42 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D2A21F873C for ; Mon, 13 Feb 2012 11:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.391 X-Spam-Level: X-Spam-Status: No, score=-3.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ELl7sbrov0T for ; Mon, 13 Feb 2012 11:26:42 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 15AF921F873B for ; Mon, 13 Feb 2012 11:26:41 -0800 (PST) Received: by ghbg16 with SMTP id g16so2977953ghb.31 for ; Mon, 13 Feb 2012 11:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uc14N8FMazCxVmX0gLYcxbwzCjKrbAeWv1jXUHeBoGk=; b=m0l3e3S52NNQgGn2qUD0ylOkEKQyWlD0m0UoVp4SScEhgDEptwT/k1L6MB9Pif/Zhm Ne6ObYLvKcmDLhg7o2bWZ97hP87nSp57CwnB4kEhNpu81rGGxvJqPX7W/JAKLe30rHsY TSHv189xAaR0NVM5WsdElqj6xJFOzQdgCWvq8= MIME-Version: 1.0 Received: by 10.60.7.102 with SMTP id i6mr4984985oea.9.1329161198011; Mon, 13 Feb 2012 11:26:38 -0800 (PST) Received: by 10.182.75.138 with HTTP; Mon, 13 Feb 2012 11:26:37 -0800 (PST) In-Reply-To: References: <201202131636.q1DGafVR006049@fs4113.wdf.sap.corp> <0600CF7A-A8CB-4E35-B729-43D626434645@virtualized.org> Date: Mon, 13 Feb 2012 14:26:37 -0500 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: therightkey@ietf.org, mrex@sap.com, David Conrad Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:26:43 -0000 On Mon, Feb 13, 2012 at 1:42 PM, Nico Williams wrot= e: > On Mon, Feb 13, 2012 at 12:32 PM, Phillip Hallam-Baker = wrote: >> +1 >> >> It is also worth pointing out that the MITM certs stopped being >> offered commercially as soon as it became public knowledge that they >> had been. >> >> Presumably the next step the companies providing this facility will >> take is to offer their own browser with the capability built in. It is >> no good jumping up and down saying people should not make such >> devices. The choice we have is whether to do the job right or let them >> do it without any input. >> >> >> What I find wrong with the MITM proxies is that they offer a >> completely transparent mechanism. The user is not notified that they >> are being logged. I think that is a broken approach because the whole >> point of accountability controls is that people behave differently >> when they know they are being watched. > > I'm confused: if this is wrong, and if preventing MITMing CAs leads to > an MITM model that is right (because the users are informed), then why > does it no good to jump up and down saying that people should not make > MITM devices? =A0It seems to me that it will have done plenty of good. Bluecoat has been selling the boxes for years, they will continue to sell them. The only difference is that now the enterprise has to install its own root into all the browsers. But that means those corporate users are not being informed that the MITM is taking place. Which means their security expectations are still being violated. > The object for me is not to prevent MITMing when the user knows. =A0I > really don't care about corporate MITM devices because I assume users > (employees, contractors) are informed. =A0Like you I care about MITM > devices that users *don't* know about. I assume that being informed means no more than being told that water contains chamicals known to the state of California to cause cancer. So no, I do not consider that an 'informed user'. > Not all spy-on-your-employees solutions are bad, thus the fact that > alternatives will arise does not necessarily bother me. =A0Only those > that can be used against users who are not informed or have no way to > avoid the MITM (employees can always... not use employer networks for > personal use). =A0Think of people in Iran, Syria, ... Iran peddles backdoored versions of Word, Windows and such. They are ahead of you there. --=20 Website: http://hallambaker.com/ From mrex@sap.com Mon Feb 13 11:35:38 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C87B21E8011 for ; Mon, 13 Feb 2012 11:35:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.118 X-Spam-Level: X-Spam-Status: No, score=-10.118 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g68+ymhc4xV6 for ; Mon, 13 Feb 2012 11:35:36 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id BDFAF21E8010 for ; Mon, 13 Feb 2012 11:35:35 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1DJZTun009159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Feb 2012 20:35:29 +0100 (MET) From: Martin Rex Message-Id: <201202131935.q1DJZLj5016560@fs4113.wdf.sap.corp> To: adam@cypherspace.org (Adam Back) Date: Mon, 13 Feb 2012 20:35:21 +0100 (MET) In-Reply-To: <20120213191711.GA8680@netbook.cypherspace.org> from "Adam Back" at Feb 13, 12 08:17:11 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: nico@cryptonector.com, therightkey@ietf.org, mrex@sap.com, adam@cypherspace.org Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:35:38 -0000 Adam Back wrote: > > I am not convinced by the legal arguments, while it is true that companies > doing egress monitoring probably warn their users; the fact that these mitm > proxies cut through SSL even on the users own hardware without warning is > going to violate the privacy expectations of many users even technically > sophisiticated because that is the normal SSL promise. And in some > countries there are rules about such things regardless of employee contracts > relating to reasonable expectation of privacy. The issue of companies that want to monitor activities of employees is a socio-political problem, not a technical one. In countries with strong civil liberties there are already legal/consitutional protections that make it a criminal offence for employers to monitor the communications of employees. In countries with weak civil liberties, such as in the US, this needs to be addressed at the political level. > > And unfortunately practice of many sites is to host one cert per machine in > their 100+ load balance farm to the point that even people looking for > anomalies are drowned by false positives with cert patrol etc. > > It would really be a lot simpler if sites could stick to one cert per > service even if its hosted on multiple machines. I do wonder if much real > security is gained by putting a separate cert on each load balanced box. That can sometimes be an artifact of the CA's licensing terms for the server certificate and/or of the particular backend software in use, or a result of the software installation options, rather than an explicit desire of the sysadmin. -Martin From brk7bx@virginia.edu Mon Feb 13 11:36:27 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E88C21E8011 for ; Mon, 13 Feb 2012 11:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36YBr1Enmll4 for ; Mon, 13 Feb 2012 11:36:26 -0800 (PST) Received: from tarragon.mail.virginia.edu (tarragon.mail.Virginia.EDU [128.143.2.35]) by ietfa.amsl.com (Postfix) with ESMTP id 17E1E21E8010 for ; Mon, 13 Feb 2012 11:36:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tarragon.mail.virginia.edu (Postfix) with ESMTP id 652A0246310 for ; Mon, 13 Feb 2012 14:36:22 -0500 (EST) Received: from tarragon.mail.virginia.edu ([127.0.0.1]) by localhost (tarragon-f.mail.virginia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiFdGx3Ur8+T for ; Mon, 13 Feb 2012 14:36:22 -0500 (EST) Received: from iron0.mail.virginia.edu (iron0-s.mail.virginia.edu [10.250.200.117]) by tarragon.mail.virginia.edu (Postfix) with ESMTP id 3005E2463AA for ; Mon, 13 Feb 2012 14:36:22 -0500 (EST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgAAO1kOU/RVdguimdsb2JhbABDsAgIIgEBAQoJDQcSBiOBcgEBAQMBAQEBDwJaEAsLEgYuIQYNAQUBDg4ZIodaCZtzCpQaiQeIRIJ8CCELAwIEBj2ECScBCwMEERKDQwSISoV/hmiLEYMVPYQg X-Sender-IP: 209.85.216.46 Received: from mail-qw0-f46.google.com ([209.85.216.46]) by iron0.mail.virginia.edu with ESMTP; 13 Feb 2012 14:36:21 -0500 Received: by mail-qw0-f46.google.com with SMTP id c10so1824787qad.12 for ; Mon, 13 Feb 2012 11:36:21 -0800 (PST) Received: by 10.229.136.199 with SMTP id s7mr10043961qct.145.1329161781764; Mon, 13 Feb 2012 11:36:21 -0800 (PST) Received: from terabyte ([137.54.21.2]) by mx.google.com with ESMTPS id eo4sm18997265qab.16.2012.02.13.11.36.20 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 11:36:21 -0800 (PST) Date: Mon, 13 Feb 2012 14:34:16 -0500 From: Benjamin Kreuter To: therightkey@ietf.org Message-ID: <20120213143416.4d8cde32@terabyte> In-Reply-To: References: <201202131636.q1DGafVR006049@fs4113.wdf.sap.corp> <0600CF7A-A8CB-4E35-B729-43D626434645@virtualized.org> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.18.9; i686-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA512; boundary="Sig_/A8Af1/rPsV21aN3aMyq=8_4"; protocol="application/pgp-signature" X-Gm-Message-State: ALoCoQmEEqzfXULg9XpgVbRtFFbk76Y+UGbTYPBlnkwwbn9t1FpVTT0mrXVRhRO8IljIABrTTBY+ Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:36:27 -0000 --Sig_/A8Af1/rPsV21aN3aMyq=8_4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 13 Feb 2012 13:32:48 -0500 Phillip Hallam-Baker wrote: > +1 >=20 > It is also worth pointing out that the MITM certs stopped being > offered commercially as soon as it became public knowledge that they > had been. Which speaks volumes about the motivation behind those certificates. > Presumably the next step the companies providing this facility will > take is to offer their own browser with the capability built in. It > is no good jumping up and down saying people should not make such > devices. The choice we have is whether to do the job right or let them > do it without any input. What we need to do is a build a system that does not make compromises when it comes to security. Jumping up and down is not necessary; build a system where MITM attacks are either infeasible or easily detected. > What I find wrong with the MITM proxies is that they offer a > completely transparent mechanism. The user is not notified that they > are being logged. I think that is a broken approach because the whole > point of accountability controls is that people behave differently > when they know they are being watched. > > I don't mean just changing the color of the address bar either. I > would want to see something like the following: >=20 > 0) The intercept capability is turned on in the browser, this would be > done using a separate tool and lock the browser to a specific > intercept cert root. We can already do this; just import the MITM root into the target browser, and if you want to prevent evasion, disable all other CAs. We do not currently see such things being done, probably because the people who want to perform MITM attacks do not want to have to do anything to the target system that might alert people to the eavesdropping. Why would they cooperate with a system that informs users about the eavesdropping, when they already have such an option available but choose not to use it? -- Ben > 1) User attempts to connect to https://www.example.com > 2) Browser throws up splash screen for 5secs stating 'Your connection > has been intercepted' > > 3) Business as usual. > > The splash screen would appear once per session with a new host and > reset periodically. >=20 > It should show the interception cert being used as well. >=20 >=20 > On Mon, Feb 13, 2012 at 1:21 PM, David Conrad > wrote: > > On Feb 13, 2012, at 8:36 AM, Martin Rex wrote: > >> The fact that there are products (client-side HTTPS proxies that > >> perform MITM and inspect content) actively sold and used, > >> which are vitally dependent on being able to exploit weaknesses > >> of the existing TLS X.509 PKI security&trust model, is a sure proof > >> that something is wrong with the existing security model. > > > > Well, it is proof that the theoretical model in which authorized > > MITM was disallowed was seen as too limiting. > > > >> I do not think there is value in maintaining backward compatible > >> weaknesses, and personally, I do not mind the slightest about > >> breaking those protocol subverting middle boxes, be it by the use > >> of TLS channel bindings, or the checking of DANE TLSA records. > > > > Pragmatically speaking, if you come up with an architecture that > > disallows people from doing what they want/need to do, they'll > > either figure out ways around it or not use that architecture. > > > > Regards, > > -drc > > > > _______________________________________________ > > therightkey mailing list > > therightkey@ietf.org > > https://www.ietf.org/mailman/listinfo/therightkey >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --=20 Benjamin R Kreuter UVA Computer Science brk7bx@virginia.edu KK4FJZ -- "If large numbers of people are interested in freedom of speech, there will be freedom of speech, even if the law forbids it; if public opinion is sluggish, inconvenient minorities will be persecuted, even if laws exist to protect them." - George Orwell --Sig_/A8Af1/rPsV21aN3aMyq=8_4 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBCgAGBQJPOWW+AAoJEOV0+MnZK9ijTpsP/RRIDXsWJeVd+h/F1KaRaYiZ yw2I7E1i92G+BqAFc6cbfPH/TIeZufCXahOVspDgUCQ577JB7vP4QJNd0g83Ti8A 3Dx7o8S06H5TtovQ4SLumRJ1HCg9/JIx0UMdhyfKhy3eSn+nbhJLjn0nDAylYIU0 6fIETj2N5CBEo3Jp04bOkKEHjp2BwU49bEg/C7eznXP5a4m59Yqh0yeilUhdk/ck g3CEbg/kHJWw0kqWkhYpU8yM9oElQynr/bITaU5qqzW2S800sbJLhgdy7Kz0Maiq D7NexumMuuTQoFLKz80Jocs1AueGuNkH3mA7BhRxeUDCDyqPNCsUncL4R20p3Sox 2DSRXtkJ9/UOckYVBRCTsiDxJ4vORpijs0cFPWFAsTo7uosm3mwDIq7Wt2bazrwi NyA5aEjVNPv75qZlzBTO+n1MQ8HbqrsRBnyONb/I1YlExLHIvhKKy7PoZn332d4e GNkZuhA1K9mo821c6oKD8srV5jDBjrrOuXIxaDynOFSLA5BUlK1madGGoccKx8F6 rxDGi/tQ5iEEuh1ATuCLgohwdEgZLF6dAOrT88g8WheyNrmAbzMSyIf62haSj8Jp Yt5l2n7o6i0qy1s5Apk1FzMjojSIO8zpPvoEGc+2aoktldjFZMV8r/DKsCjTkn2C N2Z4NsrlVpowthdDTufE =As6P -----END PGP SIGNATURE----- --Sig_/A8Af1/rPsV21aN3aMyq=8_4-- From ynir@checkpoint.com Mon Feb 13 12:20:46 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E7A21F875B for ; Mon, 13 Feb 2012 12:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80k+iUEcGRpj for ; Mon, 13 Feb 2012 12:20:44 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8A74D21F8712 for ; Mon, 13 Feb 2012 12:20:40 -0800 (PST) X-CheckPoint: {4F396CCA-3-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q1DKKcss028340; Mon, 13 Feb 2012 22:20:38 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 13 Feb 2012 22:20:38 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 13 Feb 2012 22:20:37 +0200 From: Yoav Nir To: Benjamin Kreuter Date: Mon, 13 Feb 2012 22:20:36 +0200 Thread-Topic: [therightkey] Basically, it's about keeping the CAs honest Thread-Index: AczqjPKWEJKCK4FbSimzABSuzsqNsg== Message-ID: <5A52FE60-93C4-4DBE-AE0E-46B2E11C9B98@checkpoint.com> References: <201202131636.q1DGafVR006049@fs4113.wdf.sap.corp> <0600CF7A-A8CB-4E35-B729-43D626434645@virtualized.org> <20120213143416.4d8cde32@terabyte> In-Reply-To: <20120213143416.4d8cde32@terabyte> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 20:20:46 -0000 On Feb 13, 2012, at 9:34 PM, Benjamin Kreuter wrote: > On Mon, 13 Feb 2012 13:32:48 -0500 > Phillip Hallam-Baker wrote: >=20 >> What I find wrong with the MITM proxies is that they offer a >> completely transparent mechanism. The user is not notified that they >> are being logged. I think that is a broken approach because the whole >> point of accountability controls is that people behave differently >> when they know they are being watched. >>=20 >> I don't mean just changing the color of the address bar either. I >> would want to see something like the following: >>=20 >> 0) The intercept capability is turned on in the browser, this would be >> done using a separate tool and lock the browser to a specific >> intercept cert root. >=20 > We can already do this; just import the MITM root into the target > browser, and if you want to prevent evasion, disable all other CAs. We > do not currently see such things being done, probably because the > people who want to perform MITM attacks do not want to have to do > anything to the target system that might alert people to the > eavesdropping. Why would they cooperate with a system that informs > users about the eavesdropping, when they already have such an option > available but choose not to use it? I work for a vendor of such systems. The way our customers use it, is that = they generate a CA certificate for their gateway and install the MITM cert = in the target browsers. I believe many of them use Microsoft's tools to automatically install on al= l Windows machines in the domain, but Mac users, Firefox users, Linux users= and smartphone users get the scary screens. That is how our product works,= and AFAIK the same is true for products with similar functionality from th= e likes of Blue Coat and Cisco. You might want to look at (the now expired) draft-mcgrew-tls-proxy-server-0= 0, which attempts to find a solutions that informs the client and identifie= s the proxy. Country-wide surveillence needs other means, and need to get legitimate loo= king certificates. Yoav From aerowolf@gmail.com Mon Feb 13 15:09:09 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682B721F8543 for ; Mon, 13 Feb 2012 15:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zQLAC6BsrqD for ; Mon, 13 Feb 2012 15:09:08 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF68021F8548 for ; Mon, 13 Feb 2012 15:09:08 -0800 (PST) Received: by iagf6 with SMTP id f6so5864940iag.31 for ; Mon, 13 Feb 2012 15:09:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=WRkfcmQ9mKht1Mfi0mkThy3XElmbOkONHA3FGc7YO6U=; b=CizI7Wc+wVXK+XSvAfyA0YITgiWxw6EsxcJAR+eqyll274GxHSLlUb9Y05wjKezgZz H2NHkwbZuh/JyMhcvCl9YZYnpIul2cNb2uAVeRPxJ/zCHtv+rqB5MAG8pp/CttOf3Ul8 BaCdAoiyQmSMfiVd7dWfg0/1m8GMiWuDhybRw= Received: by 10.50.104.164 with SMTP id gf4mr30518073igb.28.1329174546025; Mon, 13 Feb 2012 15:09:06 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id d15sm30518049ibf.7.2012.02.13.15.09.02 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 15:09:03 -0800 (PST) From: "Kyle Hamilton" To: mrex@sap.com Date: Mon, 13 Feb 2012 15:08:59 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgym47apsnimgp2evrs2 Cc: Nico Williams , therightkey@ietf.org Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:09:09 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgym47apsnimgp2evrs2 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit On Mon, Feb 13, 2012 at 8:36 AM, Martin Rex wrote: > The fact that there are products (client-side HTTPS proxies that > perform MITM and inspect content) actively sold and used, > which are vitally dependent on being able to exploit weaknesses > of the existing TLS X.509 PKI security&trust model, is a sure proof > that something is wrong with the existing security model. I completely agree. The existing security model does not take into account the fact that owners of networks get to impose their own security policies, and aims to do everything it can to prevent useful deployment of interoperable low-security routine key-continuity verification that isn't "pay to play". > I do not think there is value in maintaining backward compatible > weaknesses, and personally, I do not mind the slightest about breaking > those protocol subverting middle boxes, be it by the use of TLS channel > bindings, or the checking of DANE TLSA records. There are environments in which the data sent off of the network MUST NOT be unknown to the network owner/operator. This is not by any protocol standards body action, but rather by law or regulation. It's just like the original order from DARPA Command, that TCP/IP would be used on ARPAnet -- once it comes down, it's too late to argue. I think law rather trumps our desire to deprive everyone of the capacity to perform MITM. We can continue to outlaw it, in which case it will continue to exist outside of our sight. We can continue to do the things we've tried to do before, to break what currently exists and to try to prevent technological subversion in an arms race. That will only ensure that other standards bodies will step up to fill the void of workable standards for authentication, and ensure that companies will still do anything they can to make a buck and find ways to subvert our in-loco-parentis "you can't do that, it's for your own good" security model. It's time for us to get over ourselves. There might be a useful compromise: the built-in/vendor-supplied roots show a blue or a green address bar, and non-vendor-supplied roots show a yellow address bar. Eventually, this might lead to the partitioning of "vendor-supplied state identity service provider" from "these CAs are known to issue to businesses which must ensure complete knowledge of all incoming and outgoing data, but nevertheless provide a useful service to the browser user", with the latter provided by the vendor but also being shown in yellow within the application. Or, you know, any certificate that's issued to * or *.tld could just as easily be displayed in yellow. Nobody considers that it's ultimately the application developers who decide whether to allow and how to present anything we come up with. I think the existing mandate that everything be authenticated and tunneled end-to-end only hurts the IETF. We need to develop systems within models that actually work. I am here as the voice of the user and of the network administrator, the one who needs to be able to trust his hardware and software to do precisely what he expects them to, the one who needs to actually use the services we specify. -Kyle H --gmsm1.9.5eqgym47apsnimgp2evrs2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTMyMzA4NTlaMCMGCSqGSIb3DQEJBDEWBBRe1J2G47e1AjgkPKnfnqB7 5HZvYDBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAS8KIwV8CUlrvo/VMFsAg2uiu7D9tsy4vXvOIS6GACkXgvss5mYGQhnaj8qmL+0wWhAtN HA3d+fzuRLr4+nc0Agly3nHaUqN4qwVhcH0lagPktZ0KC3OolulZtna4oU8QTvDfIVPE+fP/Q2hs YAOZCMo90omSB/J/AeOh9SNvfUcgXV3bkEmZj9v6Tt3YShhCddnUwAkmDb8qfkgn9J1ZfSBErPMR Jq8ohLP1UyDlH8tbwT4rp6AkEvB/MVUUnudBGbddz16ERRWMG1SHFexwiJQvaS18eeQl2g1JILwf RSSE3ItiTBf2OeuWRlMNt0mCuHrYDJSsDlhACdMChaZ/iQAAAAAAAA== --gmsm1.9.5eqgym47apsnimgp2evrs2-- From palmer@google.com Mon Feb 13 15:16:14 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1929921E8040 for ; Mon, 13 Feb 2012 15:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3J2Pb6Zfu1pO for ; Mon, 13 Feb 2012 15:16:13 -0800 (PST) Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCD221E8020 for ; Mon, 13 Feb 2012 15:16:12 -0800 (PST) Received: by lbbgk8 with SMTP id gk8so3218771lbb.31 for ; Mon, 13 Feb 2012 15:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=kvpF22rC4XqIzLxCDzUHIZQSJP1gRrVyhKmeeVgBX/M=; b=upsLK6AJFAUY/H8ggmGv79gN1HfZt7DBBZ53R2lXkwv7yJ/OrWdHd7X/hCPx+CK/dU +1RKcN+XQh3g7XhPAObD6/YGYsblnTzPEryxm6d5ofvMZbZBE4OMInoXPpBnex58yo09 ww2IMyDM73N645Woq8s40PFFarS7Unc2HLM/o= Received: by 10.112.23.100 with SMTP id l4mr6384984lbf.24.1329174971896; Mon, 13 Feb 2012 15:16:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.23.100 with SMTP id l4mr6384975lbf.24.1329174971800; Mon, 13 Feb 2012 15:16:11 -0800 (PST) Received: by 10.112.26.129 with HTTP; Mon, 13 Feb 2012 15:16:11 -0800 (PST) In-Reply-To: References: Date: Mon, 13 Feb 2012 15:16:11 -0800 Message-ID: From: Chris Palmer To: Kyle Hamilton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnUdEUioBvYrURzyLJbPmOhULwQhRT67x4nx6YGby89MLRQXiNXbc8DJwNkf53S+4Nl8P+Wh1P/Q4Nju1GhITVigDpBkaDiS50P3ydZsOy8xWfPR3Fg7G8C0bCIMhPSHDXia255zE5OVX3YBX9zP/xRxc4sPQ== Cc: Nico Williams , therightkey@ietf.org, mrex@sap.com Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:16:14 -0000 On Mon, Feb 13, 2012 at 3:08 PM, Kyle Hamilton wrote: > We can continue to outlaw it, in which case it will continue to exist > outside of our sight. =C2=A0We can continue to do the things we've tried = to do > before, to break what currently exists and to try to prevent technologica= l > subversion in an arms race. =C2=A0That will only ensure that other standa= rds > bodies will step up to fill the void of workable standards for > authentication, and ensure that companies will still do anything they can= to > make a buck and find ways to subvert our in-loco-parentis "you can't do > that, it's for your own good" security model. =C2=A0It's time for us to g= et over > ourselves. For network operators wanting to MITM their own client devices, the solution is simple: install the MITM certificate as a trusted root certificate at the time the device is provisioned (and/or in later updates). Windows GPOs, for example. There is no need for such operators to get or use a *public* authority for this purpose. Everybody wins; what's the problem? From aerowolf@gmail.com Mon Feb 13 15:18:29 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA6321F856D for ; Mon, 13 Feb 2012 15:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ56C7pG4XCz for ; Mon, 13 Feb 2012 15:18:29 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF01821F8552 for ; Mon, 13 Feb 2012 15:18:23 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8609929obb.31 for ; Mon, 13 Feb 2012 15:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=Dg674AOz4lhFQhP+KxftN0kB1Ec5bZfCyRqxFVX8j8g=; b=jnIiVycUGuCTn0nwV+0ovZ1l8Mkiue70fWDainYq3tWAELG8KlQKa2+V+b3kXDovVo mP6XhfDhdgHB3OFSdAO/bmPsYDhIhTuRSp9PESUFYSN0YTAGiAVuK6dq7f/2lPAUM7Aa TleHjiXFGYWT+p+D9xbhy+D7xwiB16u0iv8SU= Received: by 10.60.0.195 with SMTP id 3mr5119232oeg.2.1329175103507; Mon, 13 Feb 2012 15:18:23 -0800 (PST) Received: from penango (jis1.qyv.name. [174.143.212.165]) by mx.google.com with ESMTPS id n7sm4200541oeh.4.2012.02.13.15.18.20 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 15:18:21 -0800 (PST) From: "Kyle Hamilton" To: mrex@sap.com Date: Mon, 13 Feb 2012 15:18:14 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgym4j6lwwlvxync89f2 Cc: therightkey@ietf.org, Phillip Hallam-Baker , drc@virtualized.org Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:18:29 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgym4j6lwwlvxync89f2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 DQoNCk9uIE1vbiwgRmViIDEzLCAyMDEyIGF0IDExOjIxIEFNLCBNYXJ0aW4gUmV4IDxtcmV4QHNh cC5jb20+IHdyb3RlOg0KPiBQaGlsbGlwIEhhbGxhbS1CYWtlciB3cm90ZToNCj4+DQo+PiBXaGF0 IEkgZmluZCB3cm9uZyB3aXRoIHRoZSBNSVRNIHByb3hpZXMgaXMgdGhhdCB0aGV5IG9mZmVyIGEN Cj4+IGNvbXBsZXRlbHkgdHJhbnNwYXJlbnQgbWVjaGFuaXNtLiBUaGUgdXNlciBpcyBub3Qgbm90 aWZpZWQgdGhhdCB0aGV5DQo+PiBhcmUgYmVpbmcgbG9nZ2VkLiBJIHRoaW5rIHRoYXQgaXMgYSBi cm9rZW4gYXBwcm9hY2ggYmVjYXVzZSB0aGUgd2hvbGUNCj4+IHBvaW50IG9mIGFjY291bnRhYmls aXR5IGNvbnRyb2xzIGlzIHRoYXQgcGVvcGxlIGJlaGF2ZSBkaWZmZXJlbnRseQ0KPj4gd2hlbiB0 aGV5IGtub3cgdGhleSBhcmUgYmVpbmcgd2F0Y2hlZC4NCj4NCj4gTUlUTSBwcm94aWVzIGFyZSBi YWQgaW4gc2V2ZXJhbCB3YXlzLiCgIE5vdCBvbmx5IHRoYXQgdGhleSdyZSB0cnlpbmcNCj4gdG8g aGlkZSAoYnkgZmFraW5nIHNlcnZlciBjZXJ0cyksIHRoZXkgYWxzbyBicmVha2luZyBjbGllbnQt Y2VydA0KPiBhdXRoZW50aWNhdGlvbiwgaW50ZXJmZXJlIHdpdGggVExTIGNoYW5uZWwgYmluZGlu Z3MgYW5kIHdpbGwNCj4gYnJlYWsgb3RoZXIgYXBwcm9hY2hlcyB0aGF0IGludGVuZCB0byBmaXgg dGhlIHNob3J0Y29taW5ncyBvZiB0aGUNCj4gQnJvd3NlcidzIFRMUyBYLjUwOSBQS0kgdHJ1c3Qg bW9kZWwuDQoNCkNvbnRpbnVpbmcgdG8gZG8gdGhlIHNhbWUgdGhpbmcgYW5kIGV4cGVjdGluZyBk aWZmZXJlbnQgcmVzdWx0cyBpcyBvbmUgb2YgdGhlIGRlZmluaXRpb25zIG9mIGluc2FuaXR5LCB5 b3Uga25vdz8gIE91ciBwcm9oaWJpdGlvbnMgaGF2ZSBsZWQgdG8gb3VyIHVuZW5mb3JjZWFibGUg cHJvaGliaXRpb25zIGJlaW5nIGJyb2tlbi4gIFdlIE1VU1Qgc3RvcCBwcm9oaWJpdGluZyB0aGlu Z3MsIGFuZCByZWNvZ25pemUgdGhhdCB0aGVyZSBhcmUgdmFsaWQgdXNlLWNhc2VzIHdoaWNoIG91 ciBuYXJyb3ctbWluZGVkIGludGVycHJldGF0aW9ucyBvZiAiQWJzb2x1dGUgQ29ycmVjdG5lc3Mg T3IgSXQncyBDcmFwIiBoYXZlIGZhaWxlZCB0byB0YWtlIGludG8gYWNjb3VudC4NCg0KVGhlcmUg YXJlIG1vcmUgdGhpbmdzIGluIEhlYXZlbiBhbmQgRWFydGggdGhhbiBhcmUgZHJlYW10IG9mIGlu IHlvdXIgcGhpbG9zb3BoeSwgSG9yYXRpby4gIFRoZXkgZXhpc3QgcmVnYXJkbGVzcyBvZiB3aGV0 aGVyIHdlIGFncmVlIHdpdGggdGhlbS4gIFRoZSBsZWFzdCB3ZSBjYW4gZG8gaXMgcGVybWl0IHRo ZW0uDQoNCihBbmQsIHRoZXJlJ3MgYW5vdGhlciBhc3BlY3Q6IGlmIHdlIGludGVudGlvbmFsbHkg YnJlYWsgYWxsIG9mIHRoZSBzb2Z0d2FyZSB0aGF0IGN1cnJlbnRseSBleGlzdHMsIHdlIHdpbGwg aGF2ZSBjb21taXR0ZWQgdGhlIGxhcmdlc3QgdGVjaG5pY2FsIGF0dGFjayBvbiB0aGUgaW50ZXJu YXRpb25hbCBmaW5hbmNpYWwgYW5kIGNvbW11bmljYXRpb25zIGluZnJhc3RydWN0dXJlIGluIGhp c3RvcnksIGFuZCB3ZSB3b3VsZCByaWdodGx5IGJlIGJyYW5kZWQgdGVycm9yaXN0cy4pDQoNCi1L eWxlIEgNCg== --gmsm1.9.5eqgym4j6lwwlvxync89f2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTMyMzE4MTRaMCMGCSqGSIb3DQEJBDEWBBTJ3LhDjEc2rqHj+7ul9WgV /WZGRTBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAIemsSTXcGL6lGzTdSUFj9OI7rwp3Sdh9G2Q9ujcsaMdJ9e3Zlpc5XBA/kX7K77bg+kLO 6NeJhh/11QKnUohSfS+VjziqjjMZVyB7LL67QpM8RzX9pkvHTe8ABiDlTAXO06LN9wwTNv82N3Ud cFyeiCbOxAh/dK/22IOPi6iThQ/hedxEcvfA2ji6H3kqZ4cPaavUUR+wmZ+RuVo1gmyg55mhDgtY CTwhYoOYBEHo3aXruWklU7DoQEAIGcKz61g0N97+LnYZHfOCQ2Hh44lKPtbZbwheEWUTHaggIEhC y7MhhJsfQCEXm+NhAQjoV/LON2ta1xG2yxc63zayu0HDCQAAAAAAAA== --gmsm1.9.5eqgym4j6lwwlvxync89f2-- From aerowolf@gmail.com Mon Feb 13 15:22:34 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE1D21F8671 for ; Mon, 13 Feb 2012 15:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5mtKVbGfbci for ; Mon, 13 Feb 2012 15:22:33 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CEB4A21F866D for ; Mon, 13 Feb 2012 15:22:32 -0800 (PST) Received: by iagf6 with SMTP id f6so5884046iag.31 for ; Mon, 13 Feb 2012 15:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=iU8bUTuHoe3vz2FNhd7qpJfb3HEk9o+D8rN4Y7btJbo=; b=f56vpC2M5ui6Sn4B3ZR/qt5CCWjyVTPfJpZACDMDJ1QWRBiIDqsfa3TH2Q8DthijWl pqtrTfQye7Azqo5y7raR6xxI9+qtodhNd7X6z3px1GCAsgmZGIRu8YY//1fuVHgerueI 48z9bMQ7hG5ax/QpLK01xHud0FUlxiEgfgn48= Received: by 10.42.150.200 with SMTP id b8mr24768434icw.43.1329175352416; Mon, 13 Feb 2012 15:22:32 -0800 (PST) Received: from penango (jis1.qyv.name. [174.143.212.165]) by mx.google.com with ESMTPS id nq10sm16244987igc.6.2012.02.13.15.22.28 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 15:22:30 -0800 (PST) From: "Kyle Hamilton" To: "Chris Palmer" Date: Mon, 13 Feb 2012 15:22:23 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgym4oiwddz9eiricwh2 Cc: Nico Williams , therightkey@ietf.org, mrex@sap.com Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:22:34 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgym4oiwddz9eiricwh2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 DQoNCk9uIE1vbiwgRmViIDEzLCAyMDEyIGF0IDM6MTYgUE0sIENocmlzIFBhbG1lciA8cGFsbWVy QGdvb2dsZS5jb20+IHdyb3RlOg0KPiBPbiBNb24sIEZlYiAxMywgMjAxMiBhdCAzOjA4IFBNLCBL eWxlIEhhbWlsdG9uIDxhZXJvd29sZkBnbWFpbC5jb20+IHdyb3RlOg0KPg0KPj4gV2UgY2FuIGNv bnRpbnVlIHRvIG91dGxhdyBpdCwgaW4gd2hpY2ggY2FzZSBpdCB3aWxsIGNvbnRpbnVlIHRvIGV4 aXN0DQo+PiBvdXRzaWRlIG9mIG91ciBzaWdodC4goFdlIGNhbiBjb250aW51ZSB0byBkbyB0aGUg dGhpbmdzIHdlJ3ZlIHRyaWVkIHRvIGRvDQo+PiBiZWZvcmUsIHRvIGJyZWFrIHdoYXQgY3VycmVu dGx5IGV4aXN0cyBhbmQgdG8gdHJ5IHRvIHByZXZlbnQgdGVjaG5vbG9naWNhbA0KPj4gc3VidmVy c2lvbiBpbiBhbiBhcm1zIHJhY2UuIKBUaGF0IHdpbGwgb25seSBlbnN1cmUgdGhhdCBvdGhlciBz dGFuZGFyZHMNCj4+IGJvZGllcyB3aWxsIHN0ZXAgdXAgdG8gZmlsbCB0aGUgdm9pZCBvZiB3b3Jr YWJsZSBzdGFuZGFyZHMgZm9yDQo+PiBhdXRoZW50aWNhdGlvbiwgYW5kIGVuc3VyZSB0aGF0IGNv bXBhbmllcyB3aWxsIHN0aWxsIGRvIGFueXRoaW5nIHRoZXkgY2FuIHRvDQo+PiBtYWtlIGEgYnVj ayBhbmQgZmluZCB3YXlzIHRvIHN1YnZlcnQgb3VyIGluLWxvY28tcGFyZW50aXMgInlvdSBjYW4n dCBkbw0KPj4gdGhhdCwgaXQncyBmb3IgeW91ciBvd24gZ29vZCIgc2VjdXJpdHkgbW9kZWwuIKBJ dCdzIHRpbWUgZm9yIHVzIHRvIGdldCBvdmVyDQo+PiBvdXJzZWx2ZXMuDQo+DQo+IEZvciBuZXR3 b3JrIG9wZXJhdG9ycyB3YW50aW5nIHRvIE1JVE0gdGhlaXIgb3duIGNsaWVudCBkZXZpY2VzLCB0 aGUNCj4gc29sdXRpb24gaXMgc2ltcGxlOiBpbnN0YWxsIHRoZSBNSVRNIGNlcnRpZmljYXRlIGFz IGEgdHJ1c3RlZCByb290DQo+IGNlcnRpZmljYXRlIGF0IHRoZSB0aW1lIHRoZSBkZXZpY2UgaXMg cHJvdmlzaW9uZWQgKGFuZC9vciBpbiBsYXRlcg0KPiB1cGRhdGVzKS4gV2luZG93cyBHUE9zLCBm b3IgZXhhbXBsZS4NCj4NCj4gVGhlcmUgaXMgbm8gbmVlZCBmb3Igc3VjaCBvcGVyYXRvcnMgdG8g Z2V0IG9yIHVzZSBhICpwdWJsaWMqIGF1dGhvcml0eQ0KPiBmb3IgdGhpcyBwdXJwb3NlLiBFdmVy eWJvZHkgd2luczsgd2hhdCdzIHRoZSBwcm9ibGVtPw0KDQpEbyB5b3UgaGF2ZSBhbnkgaWRlYSBo b3cgaGFyZCBzb21lIHNvZnR3YXJlICgqY291Z2gqRmlyZWZveCpjb3VnaCopIGN1cnJlbnRseSBt YWtlcyBpdCB0byBwcm92aXNpb24gdHJ1c3QgYW5jaG9ycyBmb3IgYW55dGhpbmcsIG11Y2ggbGVz cyBhbnl0aGluZyByZXNlbWJsaW5nIHRoaXMgcHVycG9zZT8gIERvIHlvdSBoYXZlIGFueSBpZGVh IGhvdyBtdWNoIGl0IGNvc3RzIHRvIGluZG9jdHJpbmF0ZSBzb21lb25lIGludG8gdGhlIHBlY3Vs aWFyIHdvcmxkdmlldyB3aGVyZSBYLjUwOSBhY3R1YWxseSBtYWtlcyBzZW5zZT8NCg0KV2UgTVVT VCBOT1QgZm9yY2UgbmV0d29yayBhbmQgc3lzdGVtcyBhZG1pbmlzdHJhdG9ycyBhbmQgaW1hZ2Ug YnVpbGRlcnMgdG8gZmlnaHQgdXMgYW5kIG91ciB3ZWxsLW1lYW5pbmcgeWV0IHVsdGltYXRlbHkg bWlzZ3VpZGVkIGF0dGVtcHRzIHRvIG1ha2UgdGhlIHdvcmxkIGEgYmV0dGVyIHBsYWNlLg0KDQot S3lsZSBI --gmsm1.9.5eqgym4oiwddz9eiricwh2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTMyMzIyMjNaMCMGCSqGSIb3DQEJBDEWBBR0GwgxuqEHFbYV/rI7GCKU GKcEZzBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAi3qquqy8dfpRZHy6bz+WxqToU6Z2MOvi+NYod+ixfE5D3aVLmrVX8Skkwi58iSiZs02o P97W8LdH8kDP4P1x92pb4mZtfbmLEGF753ta9vOW0A3/qVex7+ApM9ZqlFn/4kc3NWQsxuGt0Szb inxx7iaI+UlmkN5BXynFNecGF+MvcGElzlyI6z6aNcgxM+31X2l87rUXxr6WLN2XFfls93tesuCn NeWgL6yJzc645gojEmCj58UAuOwjoi7ZhSFUKVDh17/9ymRoYIMbx7KLsKUrTwVxpxTzQU/qZmuZ GZk40hJQP7C6wFdBSP1xEyP49lnNhuJD1et0nJ1KECWDEwAAAAAAAA== --gmsm1.9.5eqgym4oiwddz9eiricwh2-- From palmer@google.com Mon Feb 13 15:23:51 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA3121F869F for ; Mon, 13 Feb 2012 15:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucpMFEWf7+GY for ; Mon, 13 Feb 2012 15:23:48 -0800 (PST) Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2BE21F8672 for ; Mon, 13 Feb 2012 15:23:48 -0800 (PST) Received: by lbbgk8 with SMTP id gk8so3221870lbb.31 for ; Mon, 13 Feb 2012 15:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=280y6X8T7IziRa9sADS/klaVoi82WTfXSLGqQLXdD84=; b=fPfe0aJK5KqnGQKNA+APHLX0SMK9g7f7DDqvK4MF5ZXP/MVloiPsxyM8Erg0HkJBjh C3KRYbbE/41/KWvUQx57uwyaIDl//DQL6TJLKBVT3EEhHd9eBAvjMtMbCkkXL6Qm5DRd K9qloZPuF1EwzxQO8i1AKoNFuhTGaY9MrZZ0o= Received: by 10.152.110.102 with SMTP id hz6mr13947933lab.21.1329175427572; Mon, 13 Feb 2012 15:23:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.110.102 with SMTP id hz6mr13947913lab.21.1329175427282; Mon, 13 Feb 2012 15:23:47 -0800 (PST) Received: by 10.112.26.129 with HTTP; Mon, 13 Feb 2012 15:23:47 -0800 (PST) In-Reply-To: References: Date: Mon, 13 Feb 2012 15:23:47 -0800 Message-ID: From: Chris Palmer To: Kyle Hamilton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmWJQPK3E7hw5yWiC20wOmtU6MCpFCUDb/7l1H4zzSPUE3NKz+L72PW0DYxnoIo0lULXdQ48mRF7tEjKMpA4qvnAFNhbDggow1X2TT9DrU6oUcG9KlgkLVfrBXXV9eTtDMHTjPVR7CP3vt887p7iVIPCrA/xg== Cc: Nico Williams , therightkey@ietf.org, mrex@sap.com Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:23:51 -0000 On Mon, Feb 13, 2012 at 3:22 PM, Kyle Hamilton wrote: > Do you have any idea how hard some software (*cough*Firefox*cough*) > currently makes it to provision trust anchors for anything, much less > anything resembling this purpose? =C2=A0Do you have any idea how much it = costs to > indoctrinate someone into the peculiar worldview where X.509 actually mak= es > sense? > > We MUST NOT force network and systems administrators and image builders t= o > fight us and our well-meaning yet ultimately misguided attempts to make t= he > world a better place. Wow. Ok then. From martin@millnert.se Mon Feb 13 15:50:03 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8684021E8010 for ; Mon, 13 Feb 2012 15:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mg0JkfawJugB for ; Mon, 13 Feb 2012 15:50:03 -0800 (PST) Received: from ncis.csbnet.se (ncis.csbnet.se [95.80.1.101]) by ietfa.amsl.com (Postfix) with ESMTP id C665621F8546 for ; Mon, 13 Feb 2012 15:50:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ncis.csbnet.se (Postfix) with ESMTP id 6BF1672F; Tue, 14 Feb 2012 00:47:44 +0100 (CET) Received: from ncis.csbnet.se ([127.0.0.1]) by localhost (ncis.csbnet.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri+jFCEhQx+l; Tue, 14 Feb 2012 00:47:44 +0100 (CET) Received: from [192.168.120.227] (h-189-4.a189.priv.bahnhof.se [85.24.189.4]) by ncis.csbnet.se (Postfix) with ESMTPSA id C33F4D9; Tue, 14 Feb 2012 00:47:43 +0100 (CET) Message-ID: <1329176995.11318.16.camel@davinci.millnert.se> From: Martin Millnert To: Kyle Hamilton Date: Tue, 14 Feb 2012 00:49:55 +0100 In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-hlkJ77+DdgjY1IPOUe3C" X-Mailer: Evolution 3.0.3-3 Mime-Version: 1.0 Cc: Nico Williams , therightkey@ietf.org, mrex@sap.com, Chris Palmer Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 23:50:03 -0000 --=-hlkJ77+DdgjY1IPOUe3C Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2012-02-13 at 15:22 -0800, Kyle Hamilton wrote: > On Mon, Feb 13, 2012 at 3:16 PM, Chris Palmer wrote: > > On Mon, Feb 13, 2012 at 3:08 PM, Kyle Hamilton wro= te: > > For network operators wanting to MITM their own client devices, the > > solution is simple: install the MITM certificate as a trusted root > > certificate at the time the device is provisioned (and/or in later > > updates). Windows GPOs, for example. > > > > There is no need for such operators to get or use a *public* authority > > for this purpose. Everybody wins; what's the problem? >=20 > Do you have any idea how hard some software (*cough*Firefox*cough*) curre= ntly makes it to provision trust anchors for anything, much less anything r= esembling this purpose? Do you have any idea how much it costs to indoctri= nate someone into the peculiar worldview where X.509 actually makes sense? Solutions be plentiful, according to my <5 min evaluation of some search results.* /M * https://duckduckgo.com/?q=3Dfirefox+windows+group+policy&kp=3D-1 --=-hlkJ77+DdgjY1IPOUe3C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJPOaGjAAoJEKgraNdZrwxMHBkP/3eEJ1XXh0n8PGA5PyonGeQf tVN8yQT8tRO5XQ/3qZef9qFTTA0kDfUpU5vWRc49iv2NGBmBQ84o3oN95D6PwpYF U/tyeQfX2n9ClYzgFiVHzCCzRTQ6LgKeNcZ9T/lX96hvPiMApYpRIXvyEWvEnHB0 g/YUbM9rpQJgkNBaJVDQdJwMXEUFuLtuu0+Gxwt3Lfk9hn4TAmTkniUMHETWWCKG 1jMKyKUZNtElpYH/toWhRuEVvi66+vZ8/qTayjLMm6VV4E5kAfUtYAhj3VabHxNV cX/R4V54ueEtu6os+xB2ad5b+Yy8yBdUMwNOfhyweXJEdFGaSbZAQ6be3BFrrtOd K9YL4pQF4wyU96J6VkmpSLkv/v39+aYdyde6PojooskYcxC+w7v3tXI4RNt6rbcO FnG9c0yOFkLfq9fUb7hm7al49An74VjeZ+7z7eqTIrwmm9xLhgiy2MSFuhyooCeB J2nqI979NwRUcrK5gqCT+jne/Zb/yD0qyLXNIFwlSi8YZK/MTXrsIR3ECpHvf1Yv kARSTCDYvKX8EtvwComfb3m3XrON5Vvw/V0INVX6WAGChZ/OPW8GFuP1HrV6xgw+ 2AKT1MLcXfVm5aAyH1osr5pc1e6PKwG/YNmwgKxjiJYOekep7IpTEifc2YZXfKSC 6H/gEUBkXWWBVKMhFGj3 =pX/R -----END PGP SIGNATURE----- --=-hlkJ77+DdgjY1IPOUe3C-- From paul@marvell.com Mon Feb 13 16:08:05 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3052A21E801A for ; Mon, 13 Feb 2012 16:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPgLAAcISCVW for ; Mon, 13 Feb 2012 16:08:04 -0800 (PST) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9F021E8010 for ; Mon, 13 Feb 2012 16:08:04 -0800 (PST) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTzml31U+b9zfqzwZJ1iceDqUMcUCm4sp@postini.com; Mon, 13 Feb 2012 16:08:04 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 13 Feb 2012 16:06:31 -0800 From: Paul Lambert To: Kyle Hamilton , "mrex@sap.com" Date: Mon, 13 Feb 2012 16:06:31 -0800 Thread-Topic: [therightkey] Basically, it's about keeping the CAs honest Thread-Index: AczqpIFIx/2vNd4QRPmH1tcvFDpx+QABgDvA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579DA1189@SC-VEXCH2.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_7BAC95F5A7E67643AAFB2C31BEE662D01579DA1189SCVEXCH2marve_" MIME-Version: 1.0 Cc: Nico Williams , "therightkey@ietf.org" Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 00:08:05 -0000 --_002_7BAC95F5A7E67643AAFB2C31BEE662D01579DA1189SCVEXCH2marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kyle, It's ironic that you're email includes a root certificate=20 for "Startcom Class 2" that is not the same as the one=20 currently in my browser. =20 >There might be a useful compromise: the built-in/vendor-supplied roots >show a blue or a green address bar, and non-vendor-supplied roots show a >yellow address bar. =20 Bandages on a gushing artery. More irrelevant information for users to ign= ore. >I think the existing mandate that everything be authenticated and >tunneled end-to-end only hurts the IETF. We need to develop systems >within models that actually work. I am here as the voice of the user >and of the network administrator, the one who needs to be able to trust >his hardware and software to do precisely what he expects them to, the >one who needs to actually use the services we specify. No. It helps. Allowing undetectable MiTM is an enormous compromise. =20 If corporations or Governments want to monitor traffic - they simply=20 need to be the "end" from the user and security perspective. Paul --_002_7BAC95F5A7E67643AAFB2C31BEE662D01579DA1189SCVEXCH2marve_ Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" Content-Description: Verify This Message with Penango.p7s Content-Disposition: attachment; filename="Verify This Message with Penango.p7s"; size=4030; creation-date="Mon, 13 Feb 2012 23:52:18 GMT"; modification-date="Mon, 13 Feb 2012 23:52:18 GMT" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTMyMzA4NTlaMCMGCSqGSIb3DQEJBDEWBBRe1J2G47e1AjgkPKnfnqB7 5HZvYDBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAS8KIwV8CUlrvo/VMFsAg2uiu7D9tsy4vXvOIS6GACkXgvss5mYGQhnaj8qmL+0wWhAtN HA3d+fzuRLr4+nc0Agly3nHaUqN4qwVhcH0lagPktZ0KC3OolulZtna4oU8QTvDfIVPE+fP/Q2hs YAOZCMo90omSB/J/AeOh9SNvfUcgXV3bkEmZj9v6Tt3YShhCddnUwAkmDb8qfkgn9J1ZfSBErPMR Jq8ohLP1UyDlH8tbwT4rp6AkEvB/MVUUnudBGbddz16ERRWMG1SHFexwiJQvaS18eeQl2g1JILwf RSSE3ItiTBf2OeuWRlMNt0mCuHrYDJSsDlhACdMChaZ/iQAAAAAAAA== --_002_7BAC95F5A7E67643AAFB2C31BEE662D01579DA1189SCVEXCH2marve_-- From nico@cryptonector.com Mon Feb 13 16:28:59 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE3321F8622 for ; Mon, 13 Feb 2012 16:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_SHOP=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAX2ceadDqDy for ; Mon, 13 Feb 2012 16:28:59 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5354221E8010 for ; Mon, 13 Feb 2012 16:28:59 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id F0C3758406A for ; Mon, 13 Feb 2012 16:28:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Bsa1m4q14dgYgkkSxtoiW/hciA2g9s8cmpbrnDHNX2hO 1aQe2YdrknbSYLbxDCXSCZPnp9UattLpiwu/pYYFFZrPWS640tALq8ba2cPmTkZH gUEsyP5u8E/90J29UF2jiUSWU70T7+s521O0RmXJnCOPokLH3GAsO2E81CW518w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=UGuOLrlC1D8MxZMfRARCrpNoAuk=; b=FoOIOTaQx1e Y8lsT2icetwWYe4x6KTNFtMu+eUwmDDNSIoaGrN72cc+bfdeVeEPeDCnUb6MyNWb mm2ls5pMOJOT/L/1r9AaOxjPOPDcDlxYQofcxJLCVCilWwXEbhJuXYvDMwaXnjCD WtV4nwpJe3ljnYWp4z6SgJbrj7tnNpGc= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id D7301584058 for ; Mon, 13 Feb 2012 16:28:58 -0800 (PST) Received: by dakl33 with SMTP id l33so5278724dak.31 for ; Mon, 13 Feb 2012 16:28:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.226.166 with SMTP id rt6mr52459281pbc.23.1329179338484; Mon, 13 Feb 2012 16:28:58 -0800 (PST) Received: by 10.68.136.4 with HTTP; Mon, 13 Feb 2012 16:28:58 -0800 (PST) In-Reply-To: References: Date: Mon, 13 Feb 2012 18:28:58 -0600 Message-ID: From: Nico Williams To: Kyle Hamilton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: therightkey@ietf.org, mrex@sap.com Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 00:28:59 -0000 On Mon, Feb 13, 2012 at 5:08 PM, Kyle Hamilton wrote: > I think the existing mandate that everything be authenticated and tunnele= d > end-to-end only hurts the IETF. =C2=A0We need to develop systems within m= odels If it's not end-to-end it's hop-by-hop or worse: no security. So you think hop-by-hop is better than end-to-end? Yes, there are systems where only hop-by-hop security works, but generally we should prefer end-to-end. If you have a good argument for !end-to-end I'm all ears. Perhaps you don't like trusted third parties. But end-to-end doesn't imply trusted third parties. Internet scale security has required trusted third parties to date, but it's not because of the end-to-end architecture. (Or perhaps I completely misunderstood you.) Nico -- From hallam@gmail.com Mon Feb 13 17:00:23 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D993521E8022 for ; Mon, 13 Feb 2012 17:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_00=-2.599, MANGLED_SHOP=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWNa19XgYevl for ; Mon, 13 Feb 2012 17:00:21 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B616A21E8010 for ; Mon, 13 Feb 2012 17:00:21 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8731140obb.31 for ; Mon, 13 Feb 2012 17:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=u79ND6RTrtFdPWEEg1T4bIld8rxiaVRTrMRofbA9R2M=; b=sa0DckT+HOgB5ekORZDVPoAlUNEKRAr924mC1C4zY5EEOHZs50XOnPFD5+ZTASD1Nw VF3KpJ39xfi7TkBQH4OEJqvKyvoyxtYMu6T6oJ6iCCyhGwsMAb3uzZqUzJ4qhy7zxGGR DfB1Sxmsqf8qG+MF73b9Arunhf+tUpAs5rf7c= MIME-Version: 1.0 Received: by 10.182.1.104 with SMTP id 8mr13751473obl.19.1329181219856; Mon, 13 Feb 2012 17:00:19 -0800 (PST) Received: by 10.182.75.138 with HTTP; Mon, 13 Feb 2012 17:00:19 -0800 (PST) In-Reply-To: References: Date: Mon, 13 Feb 2012 20:00:19 -0500 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: therightkey@ietf.org, mrex@sap.com, Kyle Hamilton Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 01:00:24 -0000 Before quoting end to end I strongly suggest that you actually read the Clark paper because it probably does not say what you think it does. The argument is actually about complexity and strategies for addressing it. The end-to-end security model is bunk when it comes to PKI because the end points of every communication are either people or corporations and neither can do big number modular arithmetic without some form of computer support. So there will always be at least three hops in your model: Alice <-> Computer <-> Computer <-> Bob This really matters a heck of a lot when you start to consider real world issues like usability. On Mon, Feb 13, 2012 at 7:28 PM, Nico Williams wrot= e: > On Mon, Feb 13, 2012 at 5:08 PM, Kyle Hamilton wrote= : >> I think the existing mandate that everything be authenticated and tunnel= ed >> end-to-end only hurts the IETF. =A0We need to develop systems within mod= els > > If it's not end-to-end it's hop-by-hop or worse: no security. =A0So you > think hop-by-hop is better than end-to-end? =A0Yes, there are systems > where only hop-by-hop security works, but generally we should prefer > end-to-end. =A0If you have a good argument for !end-to-end I'm all ears. > > Perhaps you don't like trusted third parties. =A0But end-to-end doesn't > imply trusted third parties. =A0Internet scale security has required > trusted third parties to date, but it's not because of the end-to-end > architecture. =A0(Or perhaps I completely misunderstood you.) > > Nico > -- > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --=20 Website: http://hallambaker.com/ From aerowolf@gmail.com Mon Feb 13 17:44:29 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD08C21E8043 for ; Mon, 13 Feb 2012 17:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esvdQYfFj+vq for ; Mon, 13 Feb 2012 17:44:29 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D499121E8037 for ; Mon, 13 Feb 2012 17:44:28 -0800 (PST) Received: by iagf6 with SMTP id f6so6080913iag.31 for ; Mon, 13 Feb 2012 17:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=XA/16KzuVQXRxYLw7irpQ58b9H2gY4HmSAei7vbrErk=; b=SGvAZ0zTBx9V+KPq+Z/s97Sg1iiCUUi7xrun7GHuQ9DYzty6L5HTKiAGHHiQWmFv+M joFqDBgdlJMUDhhCEpuYNV9BXDGfFYCb3+W2qn63b1rLiWMrAxUpt37qPFT128y+g+6D pQbPhY7ukR3SLmIqoIZGledkIv2Tz/IMku0/U= Received: by 10.42.168.197 with SMTP id x5mr25378288icy.6.1329183868517; Mon, 13 Feb 2012 17:44:28 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id ng9sm23567784igc.3.2012.02.13.17.44.25 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 17:44:26 -0800 (PST) From: "Kyle Hamilton" To: "Adam Back" Date: Mon, 13 Feb 2012 17:44:21 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgym9r34zabjgptik512 Cc: Nico Williams , therightkey@ietf.org, mrex@sap.com Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 01:44:29 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgym9r34zabjgptik512 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 SWYgSSB3ZXJlIHRoZSB2b2ljZSBvZiB0aGUgdXNlciwgSSdkIGJlIGFyZ3VpbmcgZm9yIHRoZSBy aWdodCB0byBpbXBvc2UgYW5kIGVuZm9yY2UgbXkgb3duIHBlcnNvbmFsIHNlY3VyaXR5IHBvbGlj eSwgd2l0aG91dCBpbnRlcmZlcmVuY2UgZnJvbSBhbnlvbmUgZWxzZSdzIGF0dGVtcHRzIHRvIHNo b3ZlbCBwYXktdG8tcGxheSBwb2xpY2llcyBkb3duIG15IHRocm9hdC4gIEknZCBiZSBhcmd1aW5n IGZvciB0aGUgYWJpbGl0eSB0byBtYWtlIGEgY2hvaWNlIHdpdGhvdXQgaGF2aW5nIG15IHNvZnR3 YXJlIGxpYmVsLCBzbGFuZGVyLCBvciBvdGhlcndpc2UgZGVuaWdyYXRlIHRoZSBzeXN0ZW1zIHRo YXQgSSdtIHdvcmtpbmcgd2l0aC4NCg0KSWYgSSB3ZXJlIHRoZSB2b2ljZSBvZiB0aGUgdXNlciwg SSdkIGJlIGFyZ3VpbmcgZm9yIHNpbXBsaWZ5aW5nIHRoZSBwcm9jZXNzIG9mIGdldHRpbmcgY3J5 cHRvZ3JhcGh5IHRvIHdvcmssIHdpdGhvdXQgYSBwYXktdG8tcGxheSBtb2RlbC4NCg0KSWYgSSB3 ZXJlIHRoZSB2b2ljZSBvZiB0aGUgdXNlciwgSSdkIGJlIGFyZ3VpbmcgYWdhaW5zdCBwcm92aWRp bmcgZmFsc2UgYXNzdXJhbmNlcyB3aGljaCBhcmVuJ3QgYmFja2VkIHVwIGJ5IHRoZSBtb2RlbC4N Cg0KTXkgZXhhbXBsZXM6ICBTZWN1cml0aWVzIGFuZCBFeGNoYW5nZSBDb21taXNzaW9uLXJlZ3Vs YXRlZCB0cmFkaW5nIG5ldHdvcmtzLCB3aGljaCBkbyBoYXZlIHRvIHN1cHBvcnQgVExTIGJlY2F1 c2UgaXQncyB0aGUgbWFqb3IgbWVhbnMgb2YgYmVpbmcgYWJsZSB0byBwcm92aWRlIHN0cm9uZyBh dXRoZW50aWNhdGlvbiBvdmVyIGEgVlBOLiAgSW5zdXJhbmNlIGNvbXBhbmllcyAoYSBzcGVjaWZp YyBvbmUgdGhhdCBJJ20gY2VydGFpbiBvZikgd2hvIG11c3QgYXVkaXQgdG8gZW5zdXJlIHRoYXQg cmVndWxhdGVkIGZpbmFuY2lhbCBpbmZvcm1hdGlvbiBpcyBub3QgYmVpbmcgaWxsZWdhbGx5IGRp c3RyaWJ1dGVkIG91dHNpZGUgdGhlIG5ldHdvcmsuICBFZHVjYXRpb25hbCBpbnN0aXR1dGlvbnMg KGEgc3BlY2lmaWMgb25lIHRoYXQgSSdtIGNlcnRhaW4gb2YpIHdobyB1c2UgaXQgdG8gZW5zdXJl IHRoYXQgcHJvdGVjdGVkIHN0dWRlbnQgaW5mb3JtYXRpb24gaXNuJ3QgaWxsZWdhbGx5IGRpc3Ry aWJ1dGVkLiAgQW5kIG9uIGFuZCBvbiBhbmQgb24uDQoNCklmIEkgd2VyZSB0aGUgdm9pY2Ugb2Yg dGhlIHVzZXIsIEknZCBiZSBhcmd1aW5nIGFnYWluc3QgdHJ5aW5nIHRvIGltcG9zZSB3aGF0IEkg Y2FuIGFuZCBjYW4ndCBkbyB3aXRoIG15IG93biBoYXJkd2FyZSBhbmQgc29mdHdhcmUuICBJJ2Qg YmUgYXJndWluZyBhZ2FpbnN0IHRoaW5ncyB3aGljaCByZWR1Y2UgdGhlIHdpbGxpbmduZXNzIG9m IHN5c3RlbXMgdG8gY29tbXVuaWNhdGUgLS0gdGhlIGRlY2lzaW9uIG9mIHdoZXRoZXIgdG8gYWNj ZXB0IHdoYXQncyBjb21tdW5pY2F0ZWQgaXMgbWluZSBhbG9uZS4gIEkgaGF2ZSBhbiBleGNsdXNp dmUgcmlnaHQgdG8gZGV0ZXJtaW5lIHdoYXQgaGFwcGVucyBoZXJlLiAgTm8gc3RhbmRhcmRzIGJv ZHkgaGFzIGEgcmlnaHQgdG8gdGVsbCBtZSB3aGF0IEkgY2FuJ3QgZG8uICBObyBjb25zb3J0aXVt IG9mIHBlb3BsZSwgb3RoZXIgdGhhbiB0aGUgZWxlY3RlZCBsZWdpc2xhdGl2ZSBib2RpZXMsIGhh cyBhbnkgcmlnaHQgdG8gZG8gdGhhdC4NCg0KV2UgTVVTVCBwZXJtaXQgZXZlcnkgdXNlIG9mIG91 ciBwcm90b2NvbHMuICBXZSBNVVNUIGRlc2NyaWJlIHRoZSBjb21wdXRhdGlvbmFsIHByb2Nlc3Nl cyBhbmQgd2UgTVVTVCBkZWZpbmUgdGhlIGludGVuZGVkIHNlbWFudGljcywgYnV0IHdlIE1VU1Qg Tk9UIHRyeSB0byBzYWJvdGFnZSBhbnl0aGluZyB0aGF0IHRoZSBzdGFuZGFyZHMnIGltcGxlbWVu dG9ycyBvciBjb25zdW1lcnMgdHJ5IHRvIGRvLiAgSWYgd2UgZG8sIHdlJ3JlIG92ZXJzdGVwcGlu ZyB0aGUgYm91bmRzIG9mIHdoYXQgYXV0aG9yaXR5IHdlIGNhbiBsZWdpdGltYXRlbHkgY2xhaW0g YXMgc3RhbmRhcmRzIGRlc2lnbmVycy4NCg0KLUt5bGUgSA0KDQpPbiBNb24sIEZlYiAxMywgMjAx MiBhdCAzOjIyIFBNLCBBZGFtIEJhY2sgPGFkYW1AY3lwaGVyc3BhY2Uub3JnPiB3cm90ZToNCj4g SWYgeW91IGFyZSB0aGUgdm9pY2Ugb2YgdGhlIHVzZXIsIHlvdSdkIGJlIGFyZ3VpbmcgZm9yIGZy ZWVkb20gZnJvbSBtaXRtIGJ5DQo+IHJvYnVzdCBwcm90b2NvbCBkZXNpZ24uDQo+DQo+IEl0cyBu ZXdzIHRvIG1lIHRoYXQgdGhlcmUgYXJlIG5ldHdvcmtzIHRoYXQgbWFuZGF0ZSBkZWNyeXB0aW9u IG9mIGFueSBoaWdoZXINCj4gbGV2ZWwgY29tbXMgcHJvdG9jb2xzIGdvaW5nIG92ZXIgVENQL0lQ IG9uIHRoZSBuZXR3b3JrLg0KPg0KPiBDbG9zZXN0IHlvdSBnZXQgdG8gdGhhdCBraW5kIG9mIHRo aW5nIGlzIHZvaWNlIHRlbGVjb21zIHdoZXJlIHRoZSBjcnlwdG8gaXMNCj4gaG9wLWJ5LWhvcCBh bmQgbW9zdCBsaWtlbHkgYnJva2VuIGJ5IGRlc2lnbiBjaXBoZXJzIGV0YyBidXQgdGhlcmUgaXMg bm8gU1NMDQo+IG1pdG0gb2YgM2cvNGcgZ3NtLWRhdGEgZXRjIGF0IGxlYXN0IGluIHdlc3Rlcm4g Y291bnRyaWVzLCBub3IgZXZlbg0KPiBhZHZlcnRpc2VkL2FkbWl0dGVkIGFueXdoZXJlIGVsc2Uu DQo+DQo+IERpZCB5b3UgaGF2ZSBzb21lIG90aGVyIGV4YW1wbGUgaW4gbWluZD8NCj4NCj4gQWRh bQ0KPg0KPg0KPiBPbiBNb24sIEZlYiAxMywgMjAxMiBhdCAwMzowODo1OVBNIC0wODAwLCBLeWxl IEhhbWlsdG9uIHdyb3RlOg0KPj4NCj4+DQo+Pg0KPj4gT24gTW9uLCBGZWIgMTMsIDIwMTIgYXQg ODozNiBBTSwgTWFydGluIFJleCA8bXJleEBzYXAuY29tPiB3cm90ZToNCj4+Pg0KPj4+IFRoZSBm YWN0IHRoYXQgdGhlcmUgYXJlIHByb2R1Y3RzIChjbGllbnQtc2lkZSBIVFRQUyBwcm94aWVzIHRo YXQNCj4+PiBwZXJmb3JtIE1JVE0gYW5kIGluc3BlY3QgY29udGVudCkgYWN0aXZlbHkgc29sZCBh bmQgdXNlZCwNCj4+PiB3aGljaCBhcmUgdml0YWxseSBkZXBlbmRlbnQgb24gYmVpbmcgYWJsZSB0 byBleHBsb2l0IHdlYWtuZXNzZXMNCj4+PiBvZiB0aGUgZXhpc3RpbmcgVExTIFguNTA5IFBLSSBz ZWN1cml0eSZ0cnVzdCBtb2RlbCwgaXMgYSBzdXJlIHByb29mDQo+Pj4gdGhhdCBzb21ldGhpbmcg aXMgd3Jvbmcgd2l0aCB0aGUgZXhpc3Rpbmcgc2VjdXJpdHkgbW9kZWwuDQo+Pg0KPj4NCj4+IEkg Y29tcGxldGVseSBhZ3JlZS4goFRoZSBleGlzdGluZyBzZWN1cml0eSBtb2RlbCBkb2VzIG5vdCB0 YWtlIGludG8NCj4+IGFjY291bnQgdGhlIGZhY3QgdGhhdCBvd25lcnMgb2YgbmV0d29ya3MgZ2V0 IHRvIGltcG9zZSB0aGVpciBvd24gc2VjdXJpdHkNCj4+IHBvbGljaWVzLCBhbmQgYWltcyB0byBk byBldmVyeXRoaW5nIGl0IGNhbiB0byBwcmV2ZW50IHVzZWZ1bCBkZXBsb3ltZW50IG9mDQo+PiBp bnRlcm9wZXJhYmxlIGxvdy1zZWN1cml0eSByb3V0aW5lIGtleS1jb250aW51aXR5IHZlcmlmaWNh dGlvbiB0aGF0IGlzbid0DQo+PiAicGF5IHRvIHBsYXkiLg0KPj4NCj4+PiBJIGRvIG5vdCB0aGlu ayB0aGVyZSBpcyB2YWx1ZSBpbiBtYWludGFpbmluZyBiYWNrd2FyZCBjb21wYXRpYmxlDQo+Pj4g d2Vha25lc3NlcywgYW5kIHBlcnNvbmFsbHksIEkgZG8gbm90IG1pbmQgdGhlIHNsaWdodGVzdCBh Ym91dCBicmVha2luZw0KPj4+IHRob3NlIHByb3RvY29sIHN1YnZlcnRpbmcgbWlkZGxlIGJveGVz LCBiZSBpdCBieSB0aGUgdXNlIG9mIFRMUyBjaGFubmVsDQo+Pj4gYmluZGluZ3MsIG9yIHRoZSBj aGVja2luZyBvZiBEQU5FIFRMU0EgcmVjb3Jkcy4NCj4+DQo+Pg0KPj4gVGhlcmUgYXJlIGVudmly b25tZW50cyBpbiB3aGljaCB0aGUgZGF0YSBzZW50IG9mZiBvZiB0aGUgbmV0d29yayBNVVNUIE5P VA0KPj4gYmUgdW5rbm93biB0byB0aGUgbmV0d29yayBvd25lci9vcGVyYXRvci4goFRoaXMgaXMg bm90IGJ5IGFueSBwcm90b2NvbA0KPj4gc3RhbmRhcmRzIGJvZHkgYWN0aW9uLCBidXQgcmF0aGVy IGJ5IGxhdyBvciByZWd1bGF0aW9uLiCgSXQncyBqdXN0IGxpa2UgdGhlDQo+PiBvcmlnaW5hbCBv cmRlciBmcm9tIERBUlBBIENvbW1hbmQsIHRoYXQgVENQL0lQIHdvdWxkIGJlIHVzZWQgb24gQVJQ QW5ldCAtLQ0KPj4gb25jZSBpdCBjb21lcyBkb3duLCBpdCdzIHRvbyBsYXRlIHRvIGFyZ3VlLiCg SSB0aGluayBsYXcgcmF0aGVyIHRydW1wcyBvdXINCj4+IGRlc2lyZSB0byBkZXByaXZlIGV2ZXJ5 b25lIG9mIHRoZSBjYXBhY2l0eSB0byBwZXJmb3JtIE1JVE0uDQo+Pg0KPj4gV2UgY2FuIGNvbnRp bnVlIHRvIG91dGxhdyBpdCwgaW4gd2hpY2ggY2FzZSBpdCB3aWxsIGNvbnRpbnVlIHRvIGV4aXN0 DQo+PiBvdXRzaWRlIG9mIG91ciBzaWdodC4goFdlIGNhbiBjb250aW51ZSB0byBkbyB0aGUgdGhp bmdzIHdlJ3ZlIHRyaWVkIHRvIGRvDQo+PiBiZWZvcmUsIHRvIGJyZWFrIHdoYXQgY3VycmVudGx5 IGV4aXN0cyBhbmQgdG8gdHJ5IHRvIHByZXZlbnQgdGVjaG5vbG9naWNhbA0KPj4gc3VidmVyc2lv biBpbiBhbiBhcm1zIHJhY2UuIKBUaGF0IHdpbGwgb25seSBlbnN1cmUgdGhhdCBvdGhlciBzdGFu ZGFyZHMNCj4+IGJvZGllcyB3aWxsIHN0ZXAgdXAgdG8gZmlsbCB0aGUgdm9pZCBvZiB3b3JrYWJs ZSBzdGFuZGFyZHMgZm9yDQo+PiBhdXRoZW50aWNhdGlvbiwgYW5kIGVuc3VyZSB0aGF0IGNvbXBh bmllcyB3aWxsIHN0aWxsIGRvIGFueXRoaW5nIHRoZXkgY2FuIHRvDQo+PiBtYWtlIGEgYnVjayBh bmQgZmluZCB3YXlzIHRvIHN1YnZlcnQgb3VyIGluLWxvY28tcGFyZW50aXMgInlvdSBjYW4ndCBk bw0KPj4gdGhhdCwgaXQncyBmb3IgeW91ciBvd24gZ29vZCIgc2VjdXJpdHkgbW9kZWwuIKBJdCdz IHRpbWUgZm9yIHVzIHRvIGdldCBvdmVyDQo+PiBvdXJzZWx2ZXMuDQo+Pg0KPj4gVGhlcmUgbWln aHQgYmUgYSB1c2VmdWwgY29tcHJvbWlzZTogdGhlIGJ1aWx0LWluL3ZlbmRvci1zdXBwbGllZCBy b290cw0KPj4gc2hvdyBhIGJsdWUgb3IgYSBncmVlbiBhZGRyZXNzIGJhciwgYW5kIG5vbi12ZW5k b3Itc3VwcGxpZWQgcm9vdHMgc2hvdyBhDQo+PiB5ZWxsb3cgYWRkcmVzcyBiYXIuIKBFdmVudHVh bGx5LCB0aGlzIG1pZ2h0IGxlYWQgdG8gdGhlIHBhcnRpdGlvbmluZyBvZg0KPj4gInZlbmRvci1z dXBwbGllZCBzdGF0ZSBpZGVudGl0eSBzZXJ2aWNlIHByb3ZpZGVyIiBmcm9tICJ0aGVzZSBDQXMg YXJlIGtub3duDQo+PiB0byBpc3N1ZSB0byBidXNpbmVzc2VzIHdoaWNoIG11c3QgZW5zdXJlIGNv bXBsZXRlIGtub3dsZWRnZSBvZiBhbGwgaW5jb21pbmcNCj4+IGFuZCBvdXRnb2luZyBkYXRhLCBi dXQgbmV2ZXJ0aGVsZXNzIHByb3ZpZGUgYSB1c2VmdWwgc2VydmljZSB0byB0aGUgYnJvd3Nlcg0K Pj4gdXNlciIsIHdpdGggdGhlIGxhdHRlciBwcm92aWRlZCBieSB0aGUgdmVuZG9yIGJ1dCBhbHNv IGJlaW5nIHNob3duIGluIHllbGxvdw0KPj4gd2l0aGluIHRoZSBhcHBsaWNhdGlvbi4NCj4+DQo+ PiBPciwgeW91IGtub3csIGFueSBjZXJ0aWZpY2F0ZSB0aGF0J3MgaXNzdWVkIHRvICogb3IgKi50 bGQgY291bGQganVzdCBhcw0KPj4gZWFzaWx5IGJlIGRpc3BsYXllZCBpbiB5ZWxsb3cuIKBOb2Jv ZHkgY29uc2lkZXJzIHRoYXQgaXQncyB1bHRpbWF0ZWx5IHRoZQ0KPj4gYXBwbGljYXRpb24gZGV2 ZWxvcGVycyB3aG8gZGVjaWRlIHdoZXRoZXIgdG8gYWxsb3cgYW5kIGhvdyB0byBwcmVzZW50DQo+ PiBhbnl0aGluZyB3ZSBjb21lIHVwIHdpdGguDQo+Pg0KPj4gSSB0aGluayB0aGUgZXhpc3Rpbmcg bWFuZGF0ZSB0aGF0IGV2ZXJ5dGhpbmcgYmUgYXV0aGVudGljYXRlZCBhbmQgdHVubmVsZWQNCj4+ IGVuZC10by1lbmQgb25seSBodXJ0cyB0aGUgSUVURi4goFdlIG5lZWQgdG8gZGV2ZWxvcCBzeXN0 ZW1zIHdpdGhpbiBtb2RlbHMNCj4+IHRoYXQgYWN0dWFsbHkgd29yay4goEkgYW0gaGVyZSBhcyB0 aGUgdm9pY2Ugb2YgdGhlIHVzZXIgYW5kIG9mIHRoZSBuZXR3b3JrDQo+PiBhZG1pbmlzdHJhdG9y LCB0aGUgb25lIHdobyBuZWVkcyB0byBiZSBhYmxlIHRvIHRydXN0IGhpcyBoYXJkd2FyZSBhbmQN Cj4+IHNvZnR3YXJlIHRvIGRvIHByZWNpc2VseSB3aGF0IGhlIGV4cGVjdHMgdGhlbSB0bywgdGhl IG9uZSB3aG8gbmVlZHMgdG8NCj4+IGFjdHVhbGx5IHVzZSB0aGUgc2VydmljZXMgd2Ugc3BlY2lm eS4NCj4+DQo+PiAtS3lsZSBIDQo+DQo+DQo+DQo+DQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gdGhlcmlnaHRrZXkgbWFpbGluZyBsaXN0DQo+ PiB0aGVyaWdodGtleUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90aGVyaWdodGtleQ0KPg0KPg0KDQo= --gmsm1.9.5eqgym9r34zabjgptik512 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTQwMTQ0MjFaMCMGCSqGSIb3DQEJBDEWBBSNRPhbECOJP7vtwgAfhaZh jZJ6DTBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEASFGxoMtIBN6avHHUcv8bYVOUMsMvsUcTiM9BBPvYMCBwjfnNOjVEtcc+FlN6dxzjGEoo Xa5GwkLcq+F+YsnfqICIaIyCfZDwgCybz+EZxC8vVe7010tnu1i5Ja6Gwg+0KsVggaM22gbAIKs+ Vn2E9q3x7ol9xRI1SSdnapaXNxAixZ/P6hgLr0AjEZpxgIfCimo9lfiKsVL7TB4Jyjp4ZFx1LGPz KmrEr8gVnW6MjqFgf+AayDDACRjYqzt41CKQKEMWdGvoED1NOl+AUY4kLKS5J8g9zftBrR+WdBCk 2BP0li1Mg1XM7oLtoriQ6RuhZuSeatrcYWWAIbOe62ZzJwAAAAAAAA== --gmsm1.9.5eqgym9r34zabjgptik512-- From nico@cryptonector.com Tue Feb 14 11:18:28 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B8F21E801B for ; Tue, 14 Feb 2012 11:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSkU091tXJj6 for ; Tue, 14 Feb 2012 11:18:27 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 378E621F879E for ; Tue, 14 Feb 2012 11:18:27 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id CB50726C073 for ; Tue, 14 Feb 2012 11:18:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=x0ffGd9O1bbwIk5xTWxVdAEoDDqSHCLsNdr70TKuzBfG iz+1XXz7IJxa8b7EZn+5Ks2n3Hw7l9s2qtejQxPDLr+9/oCVAAEASbs5RmiaiBi5 /3O8ZNmYIGxtwroHJLoG0T0pkHIIV28szEov+WUWwGBt6sYj419NX8nIirO9mVc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=l+zWSzUxdEpRIiCR1PsPhOok4Gw=; b=YDUj0671PuY dG6GRIaON1Sq0GwARsEWWuVJWUJYp8HCxp50CyLRYMbXeF/6La2O0OUClI8ASj7q l6HXA0LFtdmsGup6MT5yTJ9EXw8o+DBtNyZ4NMg9CqARqaF5jPvw/1pP7u8Va9AI 5HedwgOq7TRmB41s673foNhoPw/OF4xk= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id B92A826C00C for ; Tue, 14 Feb 2012 11:18:26 -0800 (PST) Received: by dakl33 with SMTP id l33so245373dak.31 for ; Tue, 14 Feb 2012 11:18:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.233.231 with SMTP id tz7mr3273516pbc.91.1329247106334; Tue, 14 Feb 2012 11:18:26 -0800 (PST) Received: by 10.68.136.4 with HTTP; Tue, 14 Feb 2012 11:18:26 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Feb 2012 13:18:26 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: therightkey@ietf.org, mrex@sap.com, Kyle Hamilton Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 19:18:28 -0000 On Mon, Feb 13, 2012 at 7:00 PM, Phillip Hallam-Baker wr= ote: > Before quoting end to end I strongly suggest that you actually read > the Clark paper because it probably does not say what you think it > does. The argument is actually about complexity and strategies for > addressing it. > > The end-to-end security model is bunk when it comes to PKI because the The end-to-end model is broken whenever authentication is mediated by third parties that can MITM you or worse. This applies to PKI and Kerberos, for example. But the end-to-end model isn't entirely broken as a result. There's a pretty decent analogy to be made between off-line human behavior and on-line security protocols as far as trust establishment goes. Namely: we depend on repeatability of results for judging trustworthiness (and much else besides), and in the absence of long shared history with our peers we do tend to depend on transitivity for trust to bootstrap new pair-wise trusts. There are lots of times in the off-line world when impersonation can occur, but we act as though the risk of compromise goes down as we repeat experiences. Even beyond impersonation, trust between individuals grows over time as they show each other that they are trustworthy. But what is the on-line equivalent of this? I'd say that something roughly along the lines of cert pinning is one equivalent: "gee, servers with this cert haven't stolen all my money yet, and it's been three years, so, yeah, I trust this cert". Grant me this analogy for the sake of this argument. We can use trusted third parties to bootstrap pair-wise trusts and use those pair-wise trusts to get end-to-end security, meaning, really: establish pair-wise secret session keys that others don't get to discover, including the trusted third parties unless they're willing to MITM or collude with the peer for a very long time. If a trusted third party has to be an MITM for years to avoid discovery, they won't be an MITM at all because that's just too difficult to pull off (unless the users are an extremely captive audience). In other words: I'm arguing that while it's true that trusted third parties weaken the end-to-end security model, they don't fundamentally prevent the end-to-end model from being faithfully applied, they just add considerations, caveats, difficulties, but not insurmountable ones. > end points of every communication are either people or corporations > and neither can do big number modular arithmetic without some form of > computer support. > > So there will always be at least three hops in your model: > > Alice <-> Computer =C2=A0<-> Computer <-> Bob Sure. We make some simplifying assumptions because humans are insufficiently fast computers. Our devices speak for us, else we'd not need those devices in the first place. > This really matters a heck of a lot when you start to consider real > world issues like usability. Definitely. Nico -- From mrex@sap.com Tue Feb 14 14:56:00 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E11721F8634 for ; Tue, 14 Feb 2012 14:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.123 X-Spam-Level: X-Spam-Status: No, score=-10.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63JG80xNH+HS for ; Tue, 14 Feb 2012 14:55:59 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8671521F8630 for ; Tue, 14 Feb 2012 14:55:58 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1EMtnx4004028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Feb 2012 23:55:54 +0100 (MET) From: Martin Rex Message-Id: <201202142255.q1EMtmOA020466@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Tue, 14 Feb 2012 23:55:48 +0100 (MET) In-Reply-To: from "Kyle Hamilton" at Feb 13, 12 03:08:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: nico@cryptonector.com, therightkey@ietf.org, mrex@sap.com Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:56:00 -0000 Kyle Hamilton wrote: > > Martin Rex wrote: > > > > The fact that there are products (client-side HTTPS proxies that > > perform MITM and inspect content) actively sold and used, > > which are vitally dependent on being able to exploit weaknesses > > of the existing TLS X.509 PKI security&trust model, is a sure proof > > that something is wrong with the existing security model. > > I completely agree. The existing security model does not take into > account the fact that owners of networks get to impose their own > security policies, and aims to do everything it can to prevent useful > deployment of interoperable low-security routine key-continuity > verification that isn't "pay to play". > > > I do not think there is value in maintaining backward compatible > > weaknesses, and personally, I do not mind the slightest about breaking > > those protocol subverting middle boxes, be it by the use of TLS channel > > bindings, or the checking of DANE TLSA records. > > There are environments in which the data sent off of the network MUST NOT > be unknown to the network owner/operator. This is not by any protocol > standards body action, but rather by law or regulation. It's just like > the original order from DARPA Command, that TCP/IP would be used on ARPAnet > -- once it comes down, it's too late to argue. I think law rather trumps > our desire to deprive everyone of the capacity to perform MITM. > > We can continue to outlaw it, in which case it will continue to exist > outside of our sight. There are two solutions for this type of "usage". - Provide terminal servers that you monitor, to which your users have to dial-in when they want to connect to the outside. - set up IPsec on your network and disallow the use of TLS on your internal network (require them to use an application gateway similar to a HTTP CONNECT proxy) TLS was not designed to provide wiretapping http://tools.ietf.org/html/rfc2804 What is currently exploited is a serious flaw in the security of the trust model used by TLS. And it can be abused by evil just as easily, see the DigiNotar hack and for what it was used. Keeping rfc2804 in mind, when fixing the weaknesses in the trust model of TLS, maintaining wiretapping capabilities is *NOT* appropriate. -Martin From aerowolf@gmail.com Tue Feb 14 15:54:24 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6AA1F0C4B for ; Tue, 14 Feb 2012 15:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.865 X-Spam-Level: X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_05=-1.11, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0TKuzMoNtgA for ; Tue, 14 Feb 2012 15:54:23 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 69C461F0C44 for ; Tue, 14 Feb 2012 15:54:23 -0800 (PST) Received: by iagf6 with SMTP id f6so675200iag.31 for ; Tue, 14 Feb 2012 15:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:mime-version:content-type; bh=bvdaTuv/BTutGXGVxAb0lsNFLvuJG+HbwSHC4bP+z78=; b=CCfduy7PqRhYjeDkQpk1PJe4ipkNWYh8eNdoSqvXHJgtRDeec232xELfOC7PXcl0GQ dKC7Rw7oJoQqxyVkr8TZoHWYND7zAc6DLN86/hoxy0X62hQOGf3d6f6kwPp5eoZ4ZA9/ vFaslLEoR55TlSsfxP8Zcr/qcHbfEqCE9RAJ0= Received: by 10.50.213.41 with SMTP id np9mr38529961igc.21.1329263662965; Tue, 14 Feb 2012 15:54:22 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id ut1sm1511861igc.2.2012.02.14.15.54.19 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 15:54:20 -0800 (PST) From: "Kyle Hamilton" To: "Paul Lambert" Date: Tue, 14 Feb 2012 15:54:20 -0800 (Pacific Standard Time) Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgynl9ghpz8qwirievl2 Cc: Nico Williams , "therightkey@ietf.org" , "mrex@sap.com" Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 23:54:24 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgynl9ghpz8qwirievl2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 DQoNCk9uIE1vbiwgRmViIDEzLCAyMDEyIGF0IDQ6MDYgUE0sIFBhdWwgTGFtYmVydCA8cGF1bEBt YXJ2ZWxsLmNvbT4gd3JvdGU6DQo+IEt5bGUsDQo+DQo+IEl0J3MgaXJvbmljIHRoYXQgeW91J3Jl IGVtYWlsIGluY2x1ZGVzIGEgcm9vdCBjZXJ0aWZpY2F0ZQ0KPiBmb3IgIlN0YXJ0Y29tIENsYXNz IDIiIHRoYXQgaXMgbm90IHRoZSBzYW1lIGFzIHRoZSBvbmUNCj4gY3VycmVudGx5IGluIG15IGJy b3dzZXIuDQoNCkl0J3MgaXJvbmljIHRoYXQgaXQncyBub3QgYSByb290LCBpdCdzIGFuIGludGVy bWVkaWF0ZSB0aGF0IGNoYWlucyBmcm9tIE1vemlsbGEncyBCdWlsdC1JbiBPYmplY3QgVG9rZW46 U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkuICBJZiB5b3VyIHNvZnR3YXJlIGRvZXNu J3QgaGFuZGxlIGl0LCBpdCdzIHlvdXIgc29mdHdhcmUncyBwb2xpY3kgaW1wbGVtZW50YXRpb24g dGhhdCdzIHNvIHdlbGwtbWVhbmluZ2x5IGludmFzaXZlIGFuZCB1bndvcmthYmxlLg0KDQo+PlRo ZXJlIG1pZ2h0IGJlIGEgdXNlZnVsIGNvbXByb21pc2U6IHRoZSBidWlsdC1pbi92ZW5kb3Itc3Vw cGxpZWQgcm9vdHMNCj4+c2hvdyBhIGJsdWUgb3IgYSBncmVlbiBhZGRyZXNzIGJhciwgYW5kIG5v bi12ZW5kb3Itc3VwcGxpZWQgcm9vdHMgc2hvdyBhDQo+PnllbGxvdyBhZGRyZXNzIGJhci4NCj4N Cj4gQmFuZGFnZXMgb24gYSBndXNoaW5nIGFydGVyeS4goE1vcmUgaXJyZWxldmFudCBpbmZvcm1h dGlvbiBmb3IgdXNlcnMgdG8gaWdub3JlLg0KDQpUZWxsaW5nIHBlb3BsZSB0aGF0IHRoZXkgYXJl IGJlaW5nIGludGVyY2VwdGVkIGFuZCBNSVRNJ2QgaXMgaXJyZWxldmFudCBpbmZvcm1hdGlvbj8N Cg0KSWYgdXNlcnMgY2hvb3NlIHRvIGlnbm9yZSBiZWluZyBnaXZlbiBhIGNsZWFyIHZpc3VhbCBp bmRpY2F0b3IgdGhhdCB3aGF0IHRoZXkncmUgc2VuZGluZyB0byBhbmQgZnJvbSBhIHBhcnRpY3Vs YXIgc2l0ZSBpcyBnb2luZyB0byBiZSByZWFkIGJ5IGEgdGhpcmQgcGFydHksIHRoYXQncyB0aGVp ciBvd24gcHJvYmxlbS4gIFdlIGFyZW4ndCBwYXJlbnRzLCB3ZSBkb24ndCBoYXZlIGd1YXJkaWFu c2hpcCBvZiB0aGUgdXNlcnMsIHdlIGNhbid0IGFjdCBpbiBsb2NvIHBhcmVudGlzIGp1c3QgYmVj YXVzZSB3ZSB0aGluayB0aGF0IHdlIGtub3cgYmVzdC4gIChUaGF0J3MgaG93ICJkaWN0YXRvcnNo aXBzIiBzdGFydC4pDQoNCkF0IHN1Y2ggdGltZSBhcyBJRVRGIGlzIGNoYXJ0ZXJlZCB3aXRoIHJl Z3VsYXRpb24tbWFraW5nIGF1dGhvcml0eSwgSSdsbCBxdWl0ZSBoYXBwaWx5IGhlbHAgZHJhdyB1 cCBhdWRpdGFibGUgc3RhbmRhcmRzIG9mIGNvcnJlY3RuZXNzLiAgVW50aWwgdGhlbiwgSSdtIG5v dCBnb2luZyB0byBlbmFibGUgdW5kZXRlY3RhYmxlIG1hbiBpbiB0aGUgbWlkZGxlLiAgSSdtIGlu c3RlYWQgZ29pbmcgdG8gZW5hYmxlIGRldGVjdGFibGUgYW5kIGNvcnJlY3RseSBkaXNjbG9zZWQg bWFuIGluIHRoZSBtaWRkbGUuDQoNCkl0IGFsbCBib2lscyBkb3duIHRvLCAid2hhdCBkbyB5b3Ug dHJ1c3QgYSBjZXJ0aWZpZXIgZm9yPyIgIENlcnRpZmllcnMgb25seSBleGlzdCB0byBmYWNpbGl0 YXRlIGNvbW11bmljYXRpb24gb2YgZGF0YSBwbHVzIHBvbGljeSBhc3NvY2lhdGVkIHdpdGggdGhl IGRhdGEuICBDZXJ0aWZpZXJzIGRvIG5vdCBzZXQgcG9saWN5LCB0aGV5IG9ubHkgc2V0IHRoZSBy ZXF1aXJlbWVudHMgdG8gb2J0YWluIGEgY2VydGlmaWNhdGUgZnJvbSB0aGVpciBjZXJ0aWZpZXIu ICBJdCBpcyBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIHdoaWNoIGhhdmUgaGlzdG9yaWNhbGx5IHNl dCB0aGUgcG9saWN5LiAgSSB3YW50IHRvIGVuc3VyZSB0aGF0IHBlb3BsZSB3aG8gZG9uJ3QgcGF5 IHRvIHBsYXkgdW5kZXIgdGhlIENBIG1vZGVsIChhbmQgd2hvIGhhdmUgc292ZXJlaWduIGltbXVu aXR5IGFzIGZhciBhcyB3ZSdyZSBjb25jZXJuZWQpIGNhbiBhY3R1YWxseSBwbGF5IGFyb3VuZCB3 aXRoIHRoZSB0ZWNobm9sb2d5IHNvIHRoYXQgdGhleSBjYW4gc2VlIHdoeSB0aGV5IHdvdWxkIHdh bnQgdG8gcGF5IGZvciB0aGUgY2VydGlmaWNhdGlvbnMuDQoNClRoZSBmYWN0IHRoYXQgYXBwbGlj YXRpb25zIG1ha2UgbGFyZ2VyIHN0YXRlbWVudHMgYWJvdXQgdW50cnVzdHdvcnRoeSBjZXJ0aWZp Y2F0ZXMgdGhhbiB0aGV5IGRvIGFib3V0IHRoZSBsYWNrIG9mIGVuY3J5cHRpb24gaXMgY29tcGxl dGVseSBiYWNrd2FyZHMuDQoNCj4+SSB0aGluayB0aGUgZXhpc3RpbmcgbWFuZGF0ZSB0aGF0IGV2 ZXJ5dGhpbmcgYmUgYXV0aGVudGljYXRlZCBhbmQNCj4+dHVubmVsZWQgZW5kLXRvLWVuZCBvbmx5 IGh1cnRzIHRoZSBJRVRGLiCgV2UgbmVlZCB0byBkZXZlbG9wIHN5c3RlbXMNCj4+d2l0aGluIG1v ZGVscyB0aGF0IGFjdHVhbGx5IHdvcmsuIKBJIGFtIGhlcmUgYXMgdGhlIHZvaWNlIG9mIHRoZSB1 c2VyDQo+PmFuZCBvZiB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9yLCB0aGUgb25lIHdobyBuZWVk cyB0byBiZSBhYmxlIHRvIHRydXN0DQo+PmhpcyBoYXJkd2FyZSBhbmQgc29mdHdhcmUgdG8gZG8g cHJlY2lzZWx5IHdoYXQgaGUgZXhwZWN0cyB0aGVtIHRvLCB0aGUNCj4+b25lIHdobyBuZWVkcyB0 byBhY3R1YWxseSB1c2UgdGhlIHNlcnZpY2VzIHdlIHNwZWNpZnkuDQo+DQo+IE5vLiBJdCBoZWxw cy4goEFsbG93aW5nIHVuZGV0ZWN0YWJsZSBNaVRNIGlzIGFuIGVub3Jtb3VzIGNvbXByb21pc2Uu DQo+IElmIGNvcnBvcmF0aW9ucyBvciBHb3Zlcm5tZW50cyB3YW50IHRvIG1vbml0b3IgdHJhZmZp YyAtIHRoZXkgc2ltcGx5DQo+IG5lZWQgdG8gYmUgdGhlICJlbmQiIGZyb20gdGhlIHVzZXIgYW5k IHNlY3VyaXR5IHBlcnNwZWN0aXZlLg0KDQpJIHdhbnQgdG8gYWxsb3cgZGV0ZWN0ZWQgTWlUTSwg YXMgbG9uZyBhcyB0aGUgdXNlciBpcyB0b2xkIGFib3V0IHRoZSBkZXRlY3Rpb24uICBIb3cgaXMg dGhpcyAndW5kZXRlY3RhYmxlIE1pVE0nPw0KDQpZb3VyIHByZWp1ZGljZXMgYW5kIHByZWNvbmNl cHRpb25zIGFyZSwgaW5kZWVkLCB0aGUgcm9vdCBjYXVzZSBvZiB0aGUgcHJvYmxlbSB3aGljaCB0 aGlzIG1haWxpbmcgbGlzdCBpcyBjaGFydGVyZWQgdG8gc29sdmUuICBXaWxsIHlvdSBwbGVhc2Ug Z2l2ZSB0aGVtIHVwPyAgRG8geW91IGhhdmUgdGhlIGNhcGFjaXR5IHRvIGdpdmUgdGhlbSB1cD8N Cg0KLUt5bGUgSA0KDQo+DQo+IEt5bGUsDQo+IA0KPiBJdCdzIGlyb25pYyB0aGF0IHlvdSdyZSBl bWFpbCBpbmNsdWRlcyBhIHJvb3QgY2VydGlmaWNhdGUNCj4gZm9yICJTdGFydGNvbSBDbGFzcyAy IiB0aGF0IGlzIG5vdCB0aGUgc2FtZSBhcyB0aGUgb25lDQo+IGN1cnJlbnRseSBpbiBteSBicm93 c2VyLg0KPiANCj4gPlRoZXJlIG1pZ2h0IGJlIGEgdXNlZnVsIGNvbXByb21pc2U6IHRoZSBidWls dC1pbi92ZW5kb3Itc3VwcGxpZWQgcm9vdHMNCj4gPnNob3cgYSBibHVlIG9yIGEgZ3JlZW4gYWRk cmVzcyBiYXIsIGFuZCBub24tdmVuZG9yLXN1cHBsaWVkIHJvb3RzIHNob3cgYQ0KPiA+eWVsbG93 IGFkZHJlc3MgYmFyLg0KPiANCj4gQmFuZGFnZXMgb24gYSBndXNoaW5nIGFydGVyeS4gIE1vcmUg aXJyZWxldmFudCBpbmZvcm1hdGlvbiBmb3IgdXNlcnMgdG8gaWdub3JlLg0KPiANCj4gPkkgdGhp bmsgdGhlIGV4aXN0aW5nIG1hbmRhdGUgdGhhdCBldmVyeXRoaW5nIGJlIGF1dGhlbnRpY2F0ZWQg YW5kDQo+ID50dW5uZWxlZCBlbmQtdG8tZW5kIG9ubHkgaHVydHMgdGhlIElFVEYuICBXZSBuZWVk IHRvIGRldmVsb3Agc3lzdGVtcw0KPiA+d2l0aGluIG1vZGVscyB0aGF0IGFjdHVhbGx5IHdvcmsu ICBJIGFtIGhlcmUgYXMgdGhlIHZvaWNlIG9mIHRoZSB1c2VyDQo+ID5hbmQgb2YgdGhlIG5ldHdv cmsgYWRtaW5pc3RyYXRvciwgdGhlIG9uZSB3aG8gbmVlZHMgdG8gYmUgYWJsZSB0byB0cnVzdA0K PiA+aGlzIGhhcmR3YXJlIGFuZCBzb2Z0d2FyZSB0byBkbyBwcmVjaXNlbHkgd2hhdCBoZSBleHBl Y3RzIHRoZW0gdG8sIHRoZQ0KPiA+b25lIHdobyBuZWVkcyB0byBhY3R1YWxseSB1c2UgdGhlIHNl cnZpY2VzIHdlIHNwZWNpZnkuDQo+IA0KPiBOby4gSXQgaGVscHMuICBBbGxvd2luZyB1bmRldGVj dGFibGUgTWlUTSBpcyBhbiBlbm9ybW91cyBjb21wcm9taXNlLg0KPiBJZiBjb3Jwb3JhdGlvbnMg b3IgR292ZXJubWVudHMgd2FudCB0byBtb25pdG9yIHRyYWZmaWMgLSB0aGV5IHNpbXBseQ0KPiBu ZWVkIHRvIGJlIHRoZSAiZW5kIiBmcm9tIHRoZSB1c2VyIGFuZCBzZWN1cml0eSBwZXJzcGVjdGl2 ZS4NCj4gDQo+IFBhdWwNCj4gDQo= --gmsm1.9.5eqgynl9ghpz8qwirievl2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTQyMzU0MjBaMCMGCSqGSIb3DQEJBDEWBBQE+39tKbieLeTeMjB6Ht4R 55r9PDBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAYaGtH2U0njGuEKnH6Cosbgym8lOYHYUUfUEAtRG5BPIpDO8ZmnIrlbFuD5q6iUbFwYr1 wgg984efQmJhVbrKtm1CcSPySN8WYrRwe5QiXjWKCOCwbfPz78dAX9ifykST3QJmYJ3NIjhILyCE hlk4V5uvkfZDDkf7SMQirD4Cz7+5Tte7HG3Zqj4KMNhaMpiZEsevmF+yyn/eULuLPWVP+AtuSC8c vbT2qWHehcbpyTYPFMXfpPk6HSShaU7zbmUjoy75/ZLoLw26kzVj5y+ZQ83gGfRBSxncgi6lbrDl /kCItsLSVs7wpLlXu5vf96QJ2Izo6xUjkW9En0R935q70QAAAAAAAA== --gmsm1.9.5eqgynl9ghpz8qwirievl2-- From stephen.farrell@cs.tcd.ie Tue Feb 14 16:14:35 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28ED521E8149 for ; Tue, 14 Feb 2012 16:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKcSKY8KphQs for ; Tue, 14 Feb 2012 16:14:34 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0B621E8147 for ; Tue, 14 Feb 2012 16:14:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 11458171C17; Wed, 15 Feb 2012 00:14:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1329264872; bh=jKOhsji1hay1PV 4wLcbKoIRF48oNgyg4ap3K+lXNMxo=; b=6uUH3YZv8zvmbj30/wZMMEqBTov7BY 9YBIfyJOwXU7AC+o2EQ/rjRZqlxpPb5g+letGKEtSsD7Ra+yqUqcDhdWjQSgV5qR 5nK35rmTGOclXGytXqBFAJ0w/qi3qL8tloimvvEdnrCdv3ktAkyws+cKlRJx8bT/ CujFnQ4h5JxQS1jE0ixxipRoGO7IoejCaD1NkgAmrCnJTvUxYlQYxDyfoGwIrkPv LV2LfNHeulrLPY5JvQRzUs4ORN77gg+Bg0X/k7lr09+HQJ1Ua5LFRRTj2uMTf3Jq EwqF9QY8YF9icVgBblibneFuchN5hyCX9IRlyjRKch5ZS1lIMnXTvm+A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id X4dp6vZWdYcZ; Wed, 15 Feb 2012 00:14:32 +0000 (GMT) Received: from [10.87.48.3] (unknown [86.45.49.57]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4AEBD171C00; Wed, 15 Feb 2012 00:14:31 +0000 (GMT) Message-ID: <4F3AF8E6.4050100@cs.tcd.ie> Date: Wed, 15 Feb 2012 00:14:30 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Kyle Hamilton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Lambert , Nico Williams , "therightkey@ietf.org" , "mrex@sap.com" Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 00:14:35 -0000 So we don't have a moderator/chair for this list for now so I'll have to do for the moment... On 02/14/2012 11:54 PM, Kyle Hamilton wrote: > Your prejudices and preconceptions are, indeed, the root cause of the > problem ... The above is ad-hominem and is not suitable for an IETF list of any sort. Please desist from such behaviour. It may have been accidental of course, but does give the wrong impression. S. From aerowolf@gmail.com Tue Feb 14 18:28:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFCB21E8037 for ; Tue, 14 Feb 2012 18:28:07 -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=[AWL=1.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8AfwZ0hLdlm for ; Tue, 14 Feb 2012 18:28:06 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE6821E8010 for ; Tue, 14 Feb 2012 18:28:06 -0800 (PST) Received: by iagf6 with SMTP id f6so854655iag.31 for ; Tue, 14 Feb 2012 18:28:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=yj0cMz5fRV1TbDkx9oECzQK4hygazoS1CHqd6YXF+fw=; b=o44FlUZa2hd6Wwd+sF8V0y0f+pnyVvLWWPuoxu6MNX6Rissiv3RLxVDSskNK+R9ucq f5fY198JjamS0RCcSKWDNh+73q4A94La3WmbEfg8tdzgNagfxjzOHrJFkPuXzmybKwIc zYhils4j2nqlGbEWH4jy5zPBBs/oGBBMz3Zv8= Received: by 10.42.179.73 with SMTP id bp9mr29645417icb.10.1329272886172; Tue, 14 Feb 2012 18:28:06 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id uy10sm2178138igc.1.2012.02.14.18.28.02 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 18:28:03 -0800 (PST) From: "Kyle Hamilton" To: "Stephen Farrell" Date: Tue, 14 Feb 2012 18:28:03 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgynqr52qjqab5ulh4h2 Cc: Paul Lambert , Nico Williams , "therightkey@ietf.org" , "mrex@sap.com" Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 02:28:07 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgynqr52qjqab5ulh4h2 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit On Tue, Feb 14, 2012 at 4:14 PM, Stephen Farrell wrote: > > So we don't have a moderator/chair for this list for now > so I'll have to do for the moment... > > > On 02/14/2012 11:54 PM, Kyle Hamilton wrote: >> >> Your prejudices and preconceptions are, indeed, the root cause of the >> problem ... > The above is ad-hominem and is not suitable for an IETF list > of any sort. > > It may have been accidental of course, but does give the wrong > impression. My apologies, I meant "These", in the sense of "these prejudices and preconceptions which you (and everyone else) hold". I did not intend it as an attack or insult at all, and I am sorry that it came across as such. I shall watch my words more carefully. -Kyle H --gmsm1.9.5eqgynqr52qjqab5ulh4h2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTUwMjI4MDNaMCMGCSqGSIb3DQEJBDEWBBTcE5aXZLeIy9au0p1ysxZ4 3l6oIzBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAopu5lHN3mTGmnsw5wFxa7nZKRVbXbCtX70PRoG0hq26x3onUwUp3/Su6kfjkqyFnB7kD RzEK3DVIA/3wLbWa7lCxrpLtDIfl5PfjCzcfcBGwyCZk2cJA9mL5v34JAG6dAW8fUKACV1FINQFi VmDwfKPjOo68mvzmPQVJwKNsi332+Okw58uoBueTJNc76wkzWvo6vBQ+jgL7zFzU5+SPmfTeuj2v StImAMZqkG+CjWw2ENKUbtLTa6IDfi0z19H7ioh4mRwXWTkJnKHvyLpzIHO0O9/KnfiXo+KhQPZw nOwW9/0OpN3PxalePHvaDxqkbiNYU2IV7sMTC5v5V52mdAAAAAAAAA== --gmsm1.9.5eqgynqr52qjqab5ulh4h2-- From aerowolf@gmail.com Tue Feb 14 18:28:10 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0C521E8037 for ; Tue, 14 Feb 2012 18:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sA2qkOTNL8i for ; Tue, 14 Feb 2012 18:28:09 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C461A21E8010 for ; Tue, 14 Feb 2012 18:28:08 -0800 (PST) Received: by obbwd15 with SMTP id wd15so879464obb.31 for ; Tue, 14 Feb 2012 18:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=gJM/GH8c3lLzDofmm3wxCxJAkQkRxmnGxHV/JWqOIyI=; b=vUiXyqMnNVh0HyHrPclCjBkvuaOFEwKdoSxHJaaNMExLNJKdj/WpQdwuhpfSdY3yGA Eqj4aVUTKScPl/60QnfQfPpXAEqWGY7xiGGDS7DAthMc6sdvw0k47/QNQs2W5Mx8FtYb QUoUVtbJaxw5EDxe0wNJl/5CJktfNP3SsTFhk= Received: by 10.50.169.5 with SMTP id aa5mr8537515igc.17.1329272887052; Tue, 14 Feb 2012 18:28:07 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id ut1sm2172313igc.2.2012.02.14.18.28.02 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 18:28:03 -0800 (PST) From: "Kyle Hamilton" To: mrex@sap.com Date: Tue, 14 Feb 2012 18:28:03 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgynqr52uht0xxmxang2 Cc: nico@cryptonector.com, therightkey@ietf.org Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 02:28:10 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgynqr52uht0xxmxang2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 DQoNCk9uIFR1ZSwgRmViIDE0LCAyMDEyIGF0IDI6NTUgUE0sIE1hcnRpbiBSZXggPG1yZXhAc2Fw LmNvbT4gd3JvdGU6DQo+PiBXZSBjYW4gY29udGludWUgdG8gb3V0bGF3IGl0LCBpbiB3aGljaCBj YXNlIGl0IHdpbGwgY29udGludWUgdG8gZXhpc3QNCj4+IG91dHNpZGUgb2Ygb3VyIHNpZ2h0Lg0K Pg0KPiBUaGVyZSBhcmUgdHdvIHNvbHV0aW9ucyBmb3IgdGhpcyB0eXBlIG9mICJ1c2FnZSIuDQo+ DQo+IC0gUHJvdmlkZSB0ZXJtaW5hbCBzZXJ2ZXJzIHRoYXQgeW91IG1vbml0b3IsIHRvIHdoaWNo IHlvdXIgdXNlcnMgaGF2ZQ0KPiCgdG8gZGlhbC1pbiB3aGVuIHRoZXkgd2FudCB0byBjb25uZWN0 IHRvIHRoZSBvdXRzaWRlLg0KDQoNCg0KPg0KPiAtIHNldCB1cCBJUHNlYyBvbiB5b3VyIG5ldHdv cmsgYW5kIGRpc2FsbG93IHRoZSB1c2Ugb2YgVExTIG9uIHlvdXINCj4goGludGVybmFsIG5ldHdv cmsgKHJlcXVpcmUgdGhlbSB0byB1c2UgYW4gYXBwbGljYXRpb24gZ2F0ZXdheQ0KPiCgc2ltaWxh ciB0byBhIEhUVFAgQ09OTkVDVCBwcm94eSkNCj4NCj4NCj4gVExTIHdhcyBub3QgZGVzaWduZWQg dG8gcHJvdmlkZSB3aXJldGFwcGluZw0KPg0KPiCgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzI4MDQNCg0KVExTIHdhcyBkZXNpZ25lZCB0byBwcmV2ZW50IHVuZGV0ZWN0YWJsZSB3aXJl dGFwcGluZy4gIEl0IHdhc24ndCBkZXNpZ25lZCB0byBwcmV2ZW50IHdpcmV0YXBwaW5nIGluIGFu ZCBvZiBpdHNlbGYgYnkgb25lIG9mIHRoZSBlbmRwb2ludHMuICBBbmQgaXQgaXMgZW50aXJlbHkg bGVnaXRpbWF0ZSBmb3IgYSBjb21wYW55IHRvIGluc3RhbGwga2V5bG9nZ2VycyBhbmQgc2NyZWVu IHJlY29yZGVycyBvbiB0aGVpciBjb21wdXRlcnMgYXMgbG9uZyBhcyB0aGV5IGdldCBlbXBsb3ll ZSBzaWduYXR1cmVzIHRoYXQgdGhleSBoYXZlIGJlZW4gaW5mb3JtZWQgb2Ygc3VjaC4gIChJIHdv cmtlZCBzb21ld2hlcmUgdGhhdCBkaWQgdGhpcywgYSBsYXJnZSBsaWZlIGluc3VyYW5jZSBjb21w YW55LikNCg0KUmVnYXJkbGVzcyBvZiB3aGV0aGVyIGl0IHdhcyBkZXNpZ25lZCB0byBwZXJtaXQg b25lIHRoaW5nIG9yIHRoZSBvdGhlciwgdGhlIGZhY3QgaXMgdGhhdCBpdCBpcyBiZWluZyB1c2Vk IHN1Y2guICBXZSBjYW4ndCByZWx5IG9uIHN0YW5kYXJkcyBvZiBpbnRlbnRpb25hbCBwdXJpdHks IHdlIGhhdmUgdG8gZW5naW5lZXIgc29tZXRoaW5nIHRoYXQgd29ya3MuICAoSWYgaXQgZG9lc24n dCB3b3JrLCB3ZSdyZSBub3QgZW5naW5lZXJzLCB3ZSdyZSAibW9uZXkgc2lua3MiLikNCg0KPiBX aGF0IGlzIGN1cnJlbnRseSBleHBsb2l0ZWQgaXMgYSBzZXJpb3VzIGZsYXcgaW4gdGhlIHNlY3Vy aXR5IG9mDQo+IHRoZSB0cnVzdCBtb2RlbCB1c2VkIGJ5IFRMUy4goEFuZCBpdCBjYW4gYmUgYWJ1 c2VkIGJ5IGV2aWwganVzdCBhcw0KPiBlYXNpbHksIHNlZSB0aGUgRGlnaU5vdGFyIGhhY2sgYW5k IGZvciB3aGF0IGl0IHdhcyB1c2VkLg0KDQpXaGF0IHdhcyBleHBsb2l0ZWQgaXMgYSBzZXJpb3Vz IGZsYXcsIHllcy4gIEFuZCBhdXRob3JpdGF0aXZlIENBIGlzc3VlZCBjZXJ0aWZpY2F0ZXMgd2ls bCBhbHdheXMgYmUgaGlnaC12YWx1ZSBpdGVtcy4gIEhvd2V2ZXIsIEkgZG9uJ3QgcmVhbGx5IHRo aW5rIHRoZSBmbGF3IGlzIGluIHRoZSB0cnVzdCBtb2RlbCAidXNlZCBieSBUTFMiLg0KDQpUaGUg ZmxhdyBpcyBpbiB0aGUgdHJ1c3QgbW9kZWwgaW1wbGVtZW50ZWQgYnkgdGhlIGJyb3dzZXJzIHdo aWNoICh0YWtpbmcgaXRzIGN1ZSBmcm9tIHRoaXMgaW5zaXN0ZW5jZSBvbiBhIGJpbmFyeSAiQ29y cmVjdCIgb3IgIkNyYXAiKSBjYXRlZ29yaWNhbGx5IGNhbm5vdCBhY2tub3dsZWRnZSBkaWZmZXJl bnQgYXV0aG9yaXRpZXMgZm9yIGRpZmZlcmVudCB0YXNrcywgaW5zdGVhZCBmb3JjaW5nIGV2ZXJ5 dGhpbmcgaW50byBhIHZlcnkgc2ltcGxpc3RpYyAiZG9lcyBpdCB2ZXJpZnkgdG8gb3VyIHRydXN0 IHN0b3JlPyAgS2VlcCB0aGUgVUkgdW5jbHV0dGVyZWQsIGlmIGl0IHZlcmlmaWVzIHRvIHRoZSB0 cnVzdCBzdG9yZSBpdCdzIG9rYXkgZm9yIGV2ZXJ5dGhpbmciLg0KDQpQdXQgYW5vdGhlciB3YXks IFguNTA5IGl0c2VsZiBzYXlzIHRoYXQgdGhlIHByaXZpbGVnZSBtYW5hZ2VtZW50IGluZnJ1c3Ry dWN0dXJlIHdpbGwgYWxtb3N0IGFsd2F5cyBiZSBjb21wbGV0ZWx5IHNlcGFyYXRlIGZyb20gdGhl IGNlcnRpZmljYXRpb24gaW5mcmFzdHJ1Y3R1cmUuICBXaHkgYXJlIHdlIHVzaW5nICJ0aGUgc2lt cGxlIGV4aXN0ZW5jZSBvZiBhIGNoYWluIHdoaWNoIGdvZXMgdXAgdG8gb25lIG9mIHRoZSBtYW55 IGF1dGhvcml0aWVzIHdlIGFjY2VwdCIgYXMgdGhlIG1hcmtlciBmb3IgYW4gZXJyb3ItZnJlZSBV ST8NCg0KPiBLZWVwaW5nIHJmYzI4MDQgaW4gbWluZCwgd2hlbiBmaXhpbmcgdGhlIHdlYWtuZXNz ZXMgaW4gdGhlIHRydXN0IG1vZGVsDQo+IG9mIFRMUywgbWFpbnRhaW5pbmcgd2lyZXRhcHBpbmcg Y2FwYWJpbGl0aWVzIGlzICpOT1QqIGFwcHJvcHJpYXRlLg0KDQpJIHRoaW5rIGl0J3MgaW5jcmVk aWJseSBuYWl2ZSB0byBhZGhlcmUgdG8gdGhlIGRpcmVjdGlvbnMgYW5kIGRlbWFuZHMgb2YgYSBk b2N1bWVudCBjcmVhdGVkIG9uIHRoZSBjdXNwIG9mIGEgdGVjaG5vbG9neSB3aGljaCBzdWRkZW5s eSBoYWQgYSBtdWNoIGJyb2FkZXIgcG90ZW50aWFsIHRoYW4gaGFkIGV2ZXIgYmVlbiBjb25zaWRl cmVkIGJlZm9yZS4gIFdlJ3ZlIGdvdCB0aGUgTGF3IG9mIERlcGxveW1lbnQgSW5lcnRpYSBhZ2Fp bnN0IHVzOiBpZiB3ZSB0cnkgdG8gY3JlYXRlIHNvbWV0aGluZyB3aGljaCBicmVha3MgY29tcGF0 aWJpbGl0eSB3aXRoIGV4aXN0aW5nIHN5c3RlbXMsIG5vYm9keSB3aWxsIHVwZ3JhZGUuDQoNCkkn bSBhbGwgZm9yIGlkZWFsaXNtIC0tIGJlbGlldmUgbWUsIEkgYW0gYW4gaWRlYWxpc3Qgb2YgdGhl IGhpZ2hlc3Qgb3JkZXIuICBNeSBtYWluIGlkZWFsOiB3ZSBtdXN0IGJlIGFibGUgdG8gY29tbXVu aWNhdGUgZnJlZWx5LCB3aXRob3V0IGludGVyZmVyZW5jZSBvciB1bmFja25vd2xlZGdlZCBlYXZl c2Ryb3BwaW5nLiAgV2UndmUgaGFkIGEgbG90IG9mIGV4cGVyaWVuY2VzIGluIHRoZSBpbnRlcnZl bmluZyAxNSB5ZWFycywgYW5kIHdlIHNob3VsZCBsZWFybiBmcm9tIHRoZW0uICBXZSBzaG91bGQg cHJvYmFibHkgYWxzbyBhdm9pZCB0aGF0IGRlZmluaXRpb24gb2YgaW5zYW5pdHksICJkb2luZyB0 aGUgc2FtZSB0aGluZyBhbmQgZXhwZWN0aW5nIGEgZGlmZmVyZW50IHJlc3VsdCIuDQogDQpXZSBj YW4gY29udGludWUgdGhlIHNsaXBwZXJ5IHNsb3BlIHRvd2FyZCBhIHN0YXRlLW1hbmRhdGVkIGZ1 bGx5LXRhZ2dlZCBhbmQgZnVsbHktc3RhdGUtaWRlbnRpZmllZCBjb21tdW5pY2F0aW9ucyByZWdp bWUgYnkgY29udGludWluZyB0byBzcGVjaWZ5IEFic29sdXRlIENvcnJlY3RuZXNzLiAoTGF3IGlz IHRoZSBvbmx5IGFjdHVhbCBtYW5kYXRlLCBzbyB0aGUgb25seSBwbGFjZSB0byBtYW5kYXRlIGFu eSBwYXJ0aWN1bGFyIHZlcnNpb24gb2YgQ29ycmVjdG5lc3MgZXhpc3RzIGluIHRoZSBsZWdpc2xh dHVyZSkuICBBbHRlcm5hdGl2ZWx5LCB3ZSBjYW4gZG8gd2hhdCB3ZSdyZSBzdXBwb3NlZCB0byBi ZSBkb2luZywgd2hpY2ggaXMgYXV0aGVudGljYXRlIHRoZSBwdWJsaWMga2V5IHVzZWQgYnkgdGhl IGVuZHBvaW50IGFuZCBhdXRoZW50aWNhdGUgdGhlIHNpZ25hdHVyZXMgb24gdGhlIGNlcnRpZmlj YXRlIGNoYWluKHMpIHdoaWNoIHRlcm1pbmF0ZSB0aGVyZSwgYW5kIHNvbWVob3cgY29tbXVuaWNh dGUgdGhhdCB0byB0aGUgdXNlciBzbyB0aGF0IHNvbWVvbmUgd2hvJ3MgdW5kZXIgYXR0YWNrIGhh cyBhIGZpZ2h0aW5nIGNoYW5jZSB0byByZWFsaXplIGl0Lg0KDQpUaGUgcGVyc29uIHdobyBpcyB1 bmRlciBhdHRhY2sncyBvbmx5IHRvb2wgdG8gaGVscCBpbiB0aGF0IGRlZmVuc2UgaXMgaGlzIGNv bXB1dGVyLiAgSXMgaXQgYXBwcm9wcmlhdGUgZm9yIHRoZSBJRVRGIHRvIGxpbWl0IHRoZSBhcHBs aWNhYmlsaXR5IG9mIGl0cyBwcm90b2NvbHMsIGFuZCBzbnViIGFueSBpbXBsZW1lbnRvciB3aG8g ZXhpc3RzIGluIGEgd29ybGQgdGhhdCB3ZSBjYW4ndCBpbWFnaW5lPw0KDQpXZSBhcmVuJ3Qgc3Rh dGVzLiAgV2UgYXJlbid0IGxhd21ha2Vycy4gIFdlIGFyZW4ndCByZWd1bGF0b3JzLiAgV2UgYXJl bid0IGVuZm9yY2Vycy4gICguLi51bmxlc3MgZW1wbG95ZWQgYnkgb3IgYXMgc3VjaC4pICBZb3Vy IGlkZWEgb2YgIndoZXJlIHRoZSBsaW1pdCBzaG91bGQgYmUiIGRvZXNuJ3QgY2hhbmdlIHRoZSBm YWN0IHRoYXQgdGhlcmUgd2lsbCBhbHdheXMgZXhpc3QgbGVnaXRpbWF0ZSByZWFzb25zIHRvIHZl bnR1cmUgYmV5b25kIGl0LiAgV2UgbXVzdCBhY2tub3dsZWRnZSB0aGF0LCBhbmQgZmluZCBhIGNv bXByb21pc2Ugd2hpY2ggYWNrbm93bGVkZ2VzIHRoYXQgcGVvcGxlIHNpbXBseSB3aWxsIGJlIHBy ZXNlbnRlZCB3aXRoIHRydXN0d29ydGh5IGF1dGhvcml0YXRpdmUgQ0FzLCB1bnRydXN0d29ydGh5 IHBzZXVkby1DQXMsIGFuZCB0cnVzdHdvcnRoeSBheGlvbWF0aWMgYmluZGluZ3MsIGFuZCBhbGwg Y2F0ZWdvcmllcyB3aWxsIGJlIGJlIGNvbW1vbnBsYWNlIGV2ZW50cy4gIE5vdCBhY2tub3dsZWRn aW5nIGl0IG9ubHkgbWVhbnMgdGhhdCB3aGVuIHRoZXNlIGluZXZpdGFibGUgY2FzZXMgaGFwcGVu LCBvdXIgdXNlcnMgYW5kIGltcGxlbWVudG9ycyBhcmUgbGVmdCB3aXRob3V0IGd1aWRhbmNlIGFu ZCB3aXRob3V0IGNvbXBhdGliaWxpdHkuDQoNCkkgaGF2ZSBubyBwcm9ibGVtcyBhdCBhbGwgd2l0 aCB0aGUgb3V0cHV0IG9mIHRoZSBjdXJyZW50IGF1dGhvcml0YXRpdmUgQ0FzLiAgSSBvbmx5IGhh dmUgYSBwcm9ibGVtIHdpdGggaG93IHRoYXQgb3V0cHV0IGlzIGludGVycHJldGVkIGFuZCBhcHBs aWVkLiAgR2V0dGluZyBhIGNlcnRpZmljYXRlIGZyb20gYSBDQSAod2hpY2gsIGJ5IHRoZSB3YXks IG1ha2VzIGl0IHJhdGhlciBkaWZmaWN1bHQgdG8gc2F5ICJJJ20gdHJ5aW5nIG91dCB0aGlzIHRl Y2hub2xvZ3ksIHRoaXMgc2lnbmF0dXJlIGRvZXNuJ3QgbWVhbiBhbnl0aGluZyIpIHNob3VsZCBu b3QgYmUgcHJlcmVxdWlzaXRlLCBvciBlbHNlIHRoZSBzZWN1cml0eSBjYXBhYmlsaXRpZXMgd2ls bCBub3QgYmUgdXNlZC4gIE5vYm9keSBrbm93cyB0aGUgdmFsdWUgb2YgZW5jcnlwdGlvbiwgYmVj YXVzZSB3ZSd2ZSBtYWRlIGl0IHNvbWV0aGluZyB0aGV5IGNhbid0IHVzZS4NCg0KQWxsIHdlIChh cyB1c2VycykgcmVhbGx5IG5lZWQgaXMgdG8ga25vdyBpcyB3aGVuIHdlIGRvIG9yIGRvbid0IGhh dmUgYSB0cnVzdHdvcnRoeSBhdXRob3JpdGF0aXZlIHNpZ25hdHVyZSBjaGFpbi4gIFdlIHN0aWxs IGRlcml2ZSBiZW5lZml0IGZyb20gb3Bwb3J0dW5pc3RpYyBlbmNyeXB0aW9uOyBpdCBwcmV2ZW50 cyB3aWRlLXNjYWxlIHRyYXdsaW5nLCBmb3JjaW5nIHJlc291cmNlcyB0byBiZSBzcGVudCBvbiB0 YXJnZXRlZCBhdHRhY2tzLg0KDQpIb3cgYW5kIHdoeSBpcyB0aGUgbGFjayBvZiBhIHRydXN0d29y dGh5IHNpZ25hdHVyZSBjaGFpbiBtb3JlIGFsYXJtaW5nIHRoYW4gdGhlIGxhY2sgb2YgZW5jcnlw dGlvbiBvciBhdXRoZW50aWNhdGlvbiBhdCBhbGw/ICBBdCB0aGUgdmVyeSBsZWFzdCwgYSBrZXkg ZXhwcmVzc2VzIGEgdXNlZnVsIGlkZW50aXR5OiAiaWYgaXQncyB2ZXJpZmlhYmxlIHdpdGggdGhl IHNhbWUgcHVibGljIGtleSwgaXQgd2FzIHNpZ25lZCBieSB0aGUgaG9sZGVyIG9mIHRoZSBzYW1l IHByaXZhdGUga2V5Ii4gIEtleSBjb250aW51aXR5IGlzIHRoZSBhcHByb2FjaCB0aGF0IHRoZSBP bmUgTGFwdG9wIFBlciBDaGlsZCBwcm9qZWN0IHVzZWQuDQoNCi1LeWxlIEgNCg== --gmsm1.9.5eqgynqr52uht0xxmxang2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTUwMjI4MDNaMCMGCSqGSIb3DQEJBDEWBBSLD+uUHACr2gxsyPKS4kO+ XQEHpzBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAOiWSlzcOzS1sA5omIsyyUgaGBQZvd4ki+O4s0jK53JtWO3y0/Yk6D0XblfAgTfq+1GQc ZmKmBw6PZWvefBakThnJtVXS7qkSk8X33OQkUs57azjSJ5datXXZD/1MEUMUIPTKRPHc2froqo7y R6eb9apcxOab9qk5kJ5+1dSqYctugVQRg7PB+PGfgkdsmIeG5Yb62hBkZAVjGh8g+lJBRmUc+MTQ BtrbG0jrtRJWJdhgdrpv/EPjABCz8Le43I289hOur7tLhJyLHrYU4lNEElpjMAdZXEFGVbXCYtQm DUmh8qG+0NcmNrejKfLyQKYJTf0O7uWnaZCf2fOT9sLZXQAAAAAAAA== --gmsm1.9.5eqgynqr52uht0xxmxang2-- From paul@marvell.com Tue Feb 14 18:42:15 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB74E21E8034 for ; Tue, 14 Feb 2012 18:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.517 X-Spam-Level: X-Spam-Status: No, score=-5.517 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0aHtsOC1Idb for ; Tue, 14 Feb 2012 18:42:14 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id 6291621E8010 for ; Tue, 14 Feb 2012 18:42:14 -0800 (PST) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTzsbge3bQIg6oDPI9822atlkgVMJpSa5@postini.com; Tue, 14 Feb 2012 18:42:14 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Tue, 14 Feb 2012 18:40:55 -0800 From: Paul Lambert To: Kyle Hamilton Date: Tue, 14 Feb 2012 18:40:53 -0800 Thread-Topic: [therightkey] Basically, it's about keeping the CAs honest Thread-Index: Aczrc/rYYt3mpHukQMKX4mnMEXu3QwADkHfA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579DA14C3@SC-VEXCH2.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Nico Williams , "therightkey@ietf.org" , "mrex@sap.com" Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 02:42:16 -0000 >>>There might be a useful compromise: the built-in/vendor-supplied roots >>>show a blue or a green address bar, and non-vendor-supplied roots show >a >>>yellow address bar. >> >> Bandages on a gushing artery. More irrelevant information for users >to ignore. > >Telling people that they are being intercepted and MITM'd is irrelevant >information? Changing a color in the UI is unimportant if users cannot trust that this c= olor/indication is correct or if they do not even understand what various s= hades of untrusted mean. What point is creating a UI to say you are being = MIM'd if most of the time you would not get this indication even when you a= re MITM'd. Not all MITM will acknowledge that they are monitoring traffic.= This is what we call an adversarial environment. If we were all friendly= and worthy of trust we would agree to be gentlemen and never intercept tra= ffic. =20 Hence the analogy of taking one of those little sticky band-aids to patch a= major bleed-out. Allowing the display of a "approved" MITM disregards the= much more serious blood loss of the undetected MITM. I will concede that you could build such a MITM friendly browser for enterp= rise or Internet freedom challenged countries. It's short sited though to c= onsider just this one use case. What about my TLS protected electric meter= . I don't think it understands colors. What traffic is MITM acceptable an= d what is not? Exceptions to end-to-end security are much easier to desig= n and deploy than getting it right for traffic that needs to be protected. = Go ahead and build a MITM friendly system, but we need to solve the more i= mportant problem of unrecognized MITMs. Paul From paul@marvell.com Tue Feb 14 19:06:06 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D9021F8723 for ; Tue, 14 Feb 2012 19:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67DrXUbpIBcp for ; Tue, 14 Feb 2012 19:06:05 -0800 (PST) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 1761121F8722 for ; Tue, 14 Feb 2012 19:06:05 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTzshGXQvzfz+mKcrUqK+i7PkQa/pK4VK@postini.com; Tue, 14 Feb 2012 19:06:05 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Tue, 14 Feb 2012 19:04:10 -0800 From: Paul Lambert To: Kyle Hamilton , "mrex@sap.com" Date: Tue, 14 Feb 2012 19:04:09 -0800 Thread-Topic: [therightkey] Basically, it's about keeping the CAs honest Thread-Index: AczriXjdP7tLBF6sSPe9VA09HXd+YAAAez7Q Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579DA14D8@SC-VEXCH2.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nico@cryptonector.com" , "therightkey@ietf.org" Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 03:06:06 -0000 I notice you're still attaching a root certificate of unknown quality as pa= rt of your signature. Since it is different than my current class 2 root f= or the same named authority it may or may not be valid. If I accept your c= ertificate and root I'm potentially at risk that you will later maliciously= create MITM certs. I could work harder to validate the certificate constr= aints or attributes ... but even as a supposed expert, trying to figure out= the lineage and veractiy of a new certificate is a pain. =20 My point here is not to berate your signature, but to try and refocus some = discuss away from your pronounced requirement of allowing "approved MITMs" = and find at least one thing in your thread that I agree with. Ah ... here it is ... >The flaw is in the trust model implemented by the browsers which (taking >its cue from this insistence on a binary "Correct" or "Crap") No ... binary can be ok ... here it really is ... >categorically cannot acknowledge different authorities for different >tasks,=20 Ok. This is interesting topic. If I accept a random certificate it should= =20 be able to be constrained by the user/admin to a specific range of usage. For TLS and classic PKI, this would be a range of DNS names. Right now, all the root certs in my store can create certificates in most any range. A fundamental principle we need to consider is local end-point constraint of trust. If I could do this - then the random root cert that I accept for=20 your signature could be locally constrained to be just for you or a small domain range (e.g. an enterprise) >instead forcing everything into a very simplistic "does it verify >to our trust store? Keep the UI uncluttered, if it verifies to the >trust store it's okay for everything". > >Put another way, X.509 itself says that the privilege management >infrustructure will almost always be completely separate from the >certification infrastructure. Why are we using "the simple existence of >a chain which goes up to one of the many authorities we accept" as the >marker for an error-free UI? > >> Keeping rfc2804 in mind, when fixing the weaknesses in the trust model >> of TLS, maintaining wiretapping capabilities is *NOT* appropriate. Yes! Excellent rfc2804 statement/position and a good foundation=20 to not design in MITMs.=20 >I think it's incredibly naive to adhere to the directions and demands of >a document created on the cusp of a technology which suddenly had a much >broader potential than had ever been considered before. We've got the >Law of Deployment Inertia against us: if we try to create something >which breaks compatibility with existing systems, nobody will upgrade. Huh? MITMs are bad as a design requirement. They are easy to create if you want - go ahead, but not as a core architectural principle. Paul From carl@redhoundsoftware.com Tue Feb 14 19:15:55 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B4221E8034 for ; Tue, 14 Feb 2012 19:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT7ORHV5pshs for ; Tue, 14 Feb 2012 19:15:55 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5597321E8010 for ; Tue, 14 Feb 2012 19:15:55 -0800 (PST) Received: by qafi29 with SMTP id i29so2671203qaf.10 for ; Tue, 14 Feb 2012 19:15:54 -0800 (PST) Received: by 10.229.135.82 with SMTP id m18mr13630812qct.136.1329275754712; Tue, 14 Feb 2012 19:15:54 -0800 (PST) Received: from [192.168.1.5] (pool-173-79-172-61.washdc.fios.verizon.net. [173.79.172.61]) by mx.google.com with ESMTPS id ft9sm7760715qab.0.2012.02.14.19.15.53 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 19:15:54 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 14 Feb 2012 22:15:49 -0500 From: Carl Wallace To: Paul Lambert Message-ID: Thread-Topic: [therightkey] Basically, it's about keeping the CAs honest In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01579DA14D8@SC-VEXCH2.marvell.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQl6CnWrJf+H27JgdeSILXy69hooe0Myiij6tQCTZgbw6/DuKTfGsEyckcetrp9I/piubVSa Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 03:15:56 -0000 On 2/14/12 10:04 PM, "Paul Lambert" wrote: > >Ok. This is interesting topic. If I accept a random certificate it >should >be able to be constrained by the user/admin to a specific range of usage. >For TLS and classic PKI, this would be a range of DNS names. > >Right now, all the root certs in my store can create certificates in >most any range. A fundamental principle we need to consider is local >end-point constraint of trust. > >If I could do this - then the random root cert that I accept for >your signature could be locally constrained to be just for you or >a small domain range (e.g. an enterprise) Yep. There are specs that enable this (RFCs 5914 and 5937) but they are not in wide use. From aerowolf@gmail.com Tue Feb 14 22:09:33 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F1321E802C for ; Tue, 14 Feb 2012 22:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_20=-0.74, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPAKo+8be9sM for ; Tue, 14 Feb 2012 22:09:32 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 316E521F8562 for ; Tue, 14 Feb 2012 22:09:30 -0800 (PST) Received: by iagf6 with SMTP id f6so1132179iag.31 for ; Tue, 14 Feb 2012 22:09:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=Cvwy+jrVnDdgVZdT8L/KWaJ2eXfCUBQG/O2LEohmOPY=; b=MzO9TgQKGoXtI8XRzE5R7xv+g236yURf0L4EXBD+erDHttyxeIEjlPdOw4GFcr1Kzq Fkld1VFGzKc7jU48RjcGlDpW6QOHW89snxDu/aHl2bjO8E4Tyg+XAFPqTwp45kHkTu9q BABpazoesOrXw7lfMtJoB2I3aTdcmR30gTIw0= Received: by 10.50.160.131 with SMTP id xk3mr39633408igb.19.1329286169374; Tue, 14 Feb 2012 22:09:29 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id nq10sm23481319igc.6.2012.02.14.22.09.25 (version=SSLv3 cipher=OTHER); Tue, 14 Feb 2012 22:09:27 -0800 (PST) From: "Kyle Hamilton" To: "Paul Lambert" Date: Tue, 14 Feb 2012 22:09:25 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgynyntk2vfn4y71i1e2 Cc: "nico@cryptonector.com" , "therightkey@ietf.org" , "mrex@sap.com" Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 06:09:33 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgynyntk2vfn4y71i1e2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 DQoNCk9uIFR1ZSwgRmViIDE0LCAyMDEyIGF0IDc6MDQgUE0sIFBhdWwgTGFtYmVydCA8cGF1bEBt YXJ2ZWxsLmNvbT4gd3JvdGU6DQo+DQo+IEkgbm90aWNlIHlvdSdyZSBzdGlsbCBhdHRhY2hpbmcg YSByb290IGNlcnRpZmljYXRlIG9mIHVua25vd24gcXVhbGl0eSBhcyBwYXJ0IG9mIHlvdXIgc2ln bmF0dXJlLiCgU2luY2UgaXQgaXMgZGlmZmVyZW50IHRoYW4gbXkgY3VycmVudCBjbGFzcyAyIHJv b3QgZm9yIHRoZSBzYW1lIG5hbWVkIGF1dGhvcml0eSBpdCBtYXkgb3IgbWF5IG5vdCBiZSB2YWxp ZC4goElmIEkgYWNjZXB0IHlvdXIgY2VydGlmaWNhdGUgYW5kIHJvb3QgSSdtIHBvdGVudGlhbGx5 IGF0IHJpc2sgdGhhdCB5b3Ugd2lsbCBsYXRlciBtYWxpY2lvdXNseSBjcmVhdGUgTUlUTSBjZXJ0 cy4goEkgY291bGQgd29yayBoYXJkZXIgdG8gdmFsaWRhdGUgdGhlIGNlcnRpZmljYXRlIGNvbnN0 cmFpbnRzIG9yIGF0dHJpYnV0ZXMgLi4uIGJ1dCBldmVuIGFzIGEgc3VwcG9zZWQgZXhwZXJ0LCB0 cnlpbmcgdG8gZmlndXJlIG91dCB0aGUgbGluZWFnZSBhbmQgdmVyYWN0aXkgb2YgYSBuZXcgY2Vy dGlmaWNhdGUgaXMgYSBwYWluLg0KDQpQZWRhbnRpY2FsbHksIGFzIEkgbWVudGlvbmVkLCBpdCdz IG5vdCBhIHJvb3QuICBTL01JTUUgc3BlY2lmaWVzIHRoYXQgZXZlcnkgQ0EgaW4gdGhlIGNoYWlu IGV4Y2VwdCB0aGUgcm9vdCBiZSBpbmNsdWRlZC4NCg0KSSBtdXN0IHJ1ZWZ1bGx5IG5vdGU6IHRo ZSBmYWN0IHlvdXIgc29mdHdhcmUgZG9lc24ndCBoYW5kbGUgInN0YW5kYXJkIiBYLjUwOSBzZW1h bnRpY3Mgc2F5cyB0aGF0IHRoZSBpbXBsZW1lbnRvcnMgb2Ygb3VyIHN0YW5kYXJkcyBhcmVuJ3Qg Z2V0dGluZyBpdCByaWdodCwgZWl0aGVyLiAgV2hhdCdzIHdyb25nIGhlcmU/DQoNCj4gTXkgcG9p bnQgaGVyZSBpcyBub3QgdG8gYmVyYXRlIHlvdXIgc2lnbmF0dXJlLCBidXQgdG8gdHJ5IGFuZCBy ZWZvY3VzIHNvbWUgZGlzY3VzcyBhd2F5IGZyb20geW91ciBwcm9ub3VuY2VkIHJlcXVpcmVtZW50 IG9mIGFsbG93aW5nICJhcHByb3ZlZCBNSVRNcyIgYW5kIGZpbmQgYXQgbGVhc3Qgb25lIHRoaW5n IGluIHlvdXIgdGhyZWFkIHRoYXQgSSBhZ3JlZSB3aXRoLg0KDQpJIHVzZWQgdG8gYmUgYSBjcnlw dG8gcHVyZSBpZGVhbGlzdCwgYmVsaWV2aW5nIHRoYXQgaXQgY291bGQgc29sdmUgYWxsIGRpc3B1 dGVzLiAgVGhlbiB0aGUgcmVhbCB3b3JsZCAobGl0ZXJhbGx5ISkgc2hvdCBtZSBpbiB0aGUgYmFj ay4NCg0KTm93LCBJJ20gYSBjcnlwdG8gcHJhZ21hdGljIGlkZWFsaXN0LiAgVGhlIHdvcmxkIGhh cyBldm9sdmVkIHRoZSB3YXkgaXQgaGFzIHNpbXBseSBiZWNhdXNlIGl0IGhhcy4gIFdlIGhhdmUg dG8gZml0IGludG8gdGhpcyB3b3JsZCwgYW5kIGl0IHdvdWxkIGhlbHAgYSBsb3QgaWYgd2UgZGlk bid0IHRyeSB0byBzdXBwbGFudCB0aGUgY291cnRzLg0KDQpEb24ndCBsZXQgdGhlIGlkZWFsIGJl Y29tZSB0aGUgZW5lbXkgb2YgdGhlIGFjY2VwdGFuY2Ugb2YgbWFuYWdlbWVudCBvZiBhbGwgdXNl cyBvZiBvdXIgc3RhbmRhcmRzLg0KDQo+IEFoIC4uLiBoZXJlIGl0IGlzIC4uLg0KPg0KPj5UaGUg ZmxhdyBpcyBpbiB0aGUgdHJ1c3QgbW9kZWwgaW1wbGVtZW50ZWQgYnkgdGhlIGJyb3dzZXJzIHdo aWNoICh0YWtpbmcNCj4+aXRzIGN1ZSBmcm9tIHRoaXMgaW5zaXN0ZW5jZSBvbiBhIGJpbmFyeSAi Q29ycmVjdCIgb3IgIkNyYXAiKQ0KPg0KPiBObyAuLi4gYmluYXJ5IGNhbiBiZSBvayAuLi4gaGVy ZSBpdCByZWFsbHkgaXMgLi4uDQoNCkl0IGNhbiBiZSBva2F5LCBpbiB2ZXJ5IHNpbXBsZSBlbnZp cm9ubWVudHMuICBJbXBsZW1lbnRhdGlvbiBpcyBuZXZlciB0aGF0IHNpbXBsZS4gIEV2ZXJ5IGRl Y2lzaW9uIGlzIGFuIGFuYWxvZyBwcm9jZXNzIGluZm9ybWVkIGF0IGJlc3QgYnkgbXVsdGlwbGUg YmluYXJ5IGlucHV0cyBhbmQgYXQgd29yc3Qgd2l0aCBjb3JydXB0ZWQtYnV0LWFwcGFyZW50bHkt bGVnaXRpbWF0ZSBpbnB1dHMuICAoSWYgeW91J3JlIGNyb3NzaW5nIHRoZSBzdHJlZXQsIHlvdSBs b29rIGJvdGggZGlyZWN0aW9ucyB0byBvYnRhaW4gdGhlIGJpbmFyeSAiaXMgYSBjYXIgY29taW5n IGZyb20gdGhlIGRpcmVjdGlvbiBJJ20gbG9va2luZyIgdHdpY2UsIGFuZCBkZWNpZGUgYmFzZWQg b24gYm90aCBhbnN3ZXJzIGFuZCB3aGV0aGVyIHRoZXJlJ3MgYSBwZWRlc3RyaWFuIGlzbGFuZCBp biB0aGUgbWlkZGxlIHdoZXRoZXIgdG8gZ28uKQ0KDQpNeSBnb2FsOiBHZXQgZXZlcnkgbWVzc2Fn ZSBvbiB0aGUgSW50ZXJuZXQgZW5jcnlwdGVkIGJ5IERlY2VtYmVyIDIwMTcuICBJIGtub3cgaXQn cyB1bmF0dGFpbmFibGUsIGJ1dCBpdCdzIHdoYXQgSSdtIHNob290aW5nIGZvci4NCg0KPj5jYXRl Z29yaWNhbGx5IGNhbm5vdCBhY2tub3dsZWRnZSBkaWZmZXJlbnQgYXV0aG9yaXRpZXMgZm9yIGRp ZmZlcmVudA0KPj50YXNrcywNCj4NCj4gT2suIFRoaXMgaXMgaW50ZXJlc3RpbmcgdG9waWMuIKBJ ZiBJIGFjY2VwdCBhIHJhbmRvbSBjZXJ0aWZpY2F0ZSBpdCBzaG91bGQNCj4gYmUgYWJsZSB0byBi ZSBjb25zdHJhaW5lZCBieSB0aGUgdXNlci9hZG1pbiB0byBhIHNwZWNpZmljIHJhbmdlIG9mIHVz YWdlLg0KPiBGb3IgVExTIGFuZCBjbGFzc2ljIFBLSSwgdGhpcyB3b3VsZCBiZSBhIHJhbmdlIG9m IEROUyBuYW1lcy4NCg0KSSBhZ3JlZTogSSwgYXMgbXkgb3duIHBvbGljeS1jcmVhdGluZyBwcmlu Y2lwYWwsIHNob3VsZCBiZSBwZXJtaXR0ZWQgdG8gYmUgYWJsZSB0byB3aGltc2ljYWxseSBkaXNy ZWdhcmQgYW55IHN0YXRlbWVudCB3aGljaCBJIGRvbid0IGJlbGlldmUgaXMgbGVnaXRpbWF0ZS4g IChUaGlzIGhhcHBlbnMgaW4gc3VjaCBjYXNlcyBhcyB0aGUgQ2hpbmVzZSBHb3Zlcm5tZW50IENB LikNCg0KU2VlLCBETlMgbmFtZXMgYXJlIGhlbGQgYnkgYW4gQXV0aG9yaXR5IChJQ0FOTiwgY3Jl YXRlZCBhbmQgZXhwbGljaXRseSBjaGFydGVyZWQgYnkgVVMgZmVkZXJhbCBsYXcpLiAgSW5kaXZp ZHVhbCBuYW1lcyBhcmUgaGVsZCBieSB0aGUgcHVibGljIHJlZ2lzdHJ5IG9mIGJpcnRoIGFuZCBk ZWF0aCAoYW5vdGhlciBBdXRob3JpdHkpLCBhbmQgY29ycG9yYXRlIG5hbWVzIGFyZSBoZWxkIGJ5 IHRoZSBTZWNyZXRhcmllcyBvZiBTdGF0ZSBvZiB0aGUgdmFyaW91cyBqdXJpc2RpY3Rpb25zIChh bHNvIGFuIEF1dGhvcml0eSkuICBFYWNoIG9mIHRoZXNlIGlzIHVzZWZ1bCBpbiBhIGRpZmZlcmVu dCBjb250ZXh0IGFuZCBmb3IgYSBkaWZmZXJlbnQgcHVycG9zZS4gIFRyYWRlbWFya3MgYW5kIHBh dGVudHMgYW5kIGNvcHlyaWdodHMgYXJlIGFsc28gaGVsZCBhbmQgcmVnaXN0ZXJlZCBieSBBdXRo b3JpdHksIGFuZCBhcmUgYXMgbXVjaCBwcm9wZXJ0eSBhcyBhIHBob25lIG9yIHZlaGljbGUgb3Ig c2VsZi1sYWJlbCBpcy4gIFdoeSBjYW4ndCBJIGhhdmUgYSBjZXJ0aWZpY2F0ZSBjaGFpbiBvbiB0 aGUgaW1wbGVtZW50YXRpb25zIEkgcHVyY2hhc2UgbGljZW5zZXMgdG8gd2hpY2ggc3RhdGUgdGhh dCBhIGdpdmVuIHBhdGVudCBpcyBvZmZpY2lhbGx5IGxpY2Vuc2VkPyAgT2gsIHRoYXQncyByaWdo dCwgYmVjYXVzZSBub3QgZXZlcnkgYXV0aG9yaXRhdGl2ZSByZWdpc3RyYXRpb24gaXMgaW1wb3J0 YW50IGVub3VnaCB0byBiZSBjZXJ0aWZpYWJsZS4NCg0KVGhlIENBcyB3ZSdyZSB0cnVzdGluZyBh cmUgdHJ1c3RlZCB0byBvbmx5IHN1cHBseSBpbmZvcm1hdGlvbiBhYm91dCB0aGUga2V5aG9sZGVy IHdoaWNoIHRoZSBrZXlob2xkZXIgY2FuIGxlZ2l0aW1hdGVseSBjbGFpbSB0byBvd24gdmlhIGEg cmVnaXN0ZXIgbWFpbnRhaW5lZCBieSBBdXRob3JpdHkuICAoV2hpbGUgeW91IGRvbid0IG5lY2Vz c2FyaWx5IG93biB5b3VyIG93biBuYW1lLCB5b3UgY2FuIGRlY2lkZSB3aGF0IHlvdSdyZSBuYW1l ZC4pDQoNCk5hbWVzIGFyZSBsYWJlbHMgZm9yIHBlb3BsZS4gIFB1YmxpYyBrZXlzIGFyZSBsYWJl bHMgZm9yIHRoZWlyIHByaXZhdGUga2V5cywgd2hpY2ggYXJlIGtub3duIG9yIGF2YWlsYWJsZSBv bmx5IHRvIHRoZWlyIGhvbGRlcnMuICBQcml2YXRlIGtleSBob2xkZXJzIGFyZSBwZW9wbGUgKG9y IGhhcmR3YXJlIGVtcGxveWVkIGJ5IHBlb3BsZSkuICBTbywgSSdtIGdvaW5nIHRvIGdvIG91dCBv biBhIGxpbWIgYW5kIHN1Z2dlc3QgdGhhdCAicHVibGljIGtleXMgY2FuIGJlIGNvbnNpZGVyZWQg dG8gYmUgbGFiZWxzIGZvciBwZW9wbGUiLCB3aGljaCByZWR1Y2VzIHRvICJwdWJsaWMga2V5cyBj YW4gYmUgY29uc2lkZXJlZCB0byBiZSBuYW1lcyIuDQoNCk9uZSBoYXMgdGhlIHJpZ2h0IHRvIGNo b29zZSB3aGF0IGlkZW50aXRpZXMgaGUgcHV0cyBmb3J0aCBpbiBhbnkgZW52aXJvbm1lbnQsIGFu ZCBoZSBvd25zIHRoZSByZXB1dGF0aW9uIGhlJ3MgYnVpbHQgdXAgb3ZlciB0aW1lIHVuZGVyIHRo b3NlIGlkZW50aXRpZXMuICBUaGlzIGlzIHdoeSB0aGluZ3MgbGlrZSBpZGVudGl0eSB0aGVmdCAo aW1wZXJzb25hdGlvbiBmcmF1ZCkgYXJlIGJhZCwgdGhleSByb2IgcGVvcGxlIG9mIHRoZSB0aW1l IHRoZXkgaW52ZXN0ZWQuICBIb3dldmVyLCBoZSBkb2VzIG5vdCBoYXZlIHRoZSByaWdodCBmb3Ig b3RoZXJzIG5vdCB0byBhc2sgYWJvdXQgaGltLiAgQW55IGlkZW50aXR5J3MgcmVwdXRhdGlvbiBj YW4gYmUgY2hlY2tlZCBpbnN0YW50bHkgb25jZSB0aGF0IGlkZW50aXR5IGlzIGtub3duLCBzdWJq ZWN0IG9ubHkgdG8gbGltaXRzIHBsYWNlZCBieSBsYXcgb24gZmluYW5jaWFsLCBoZWFsdGgsIGFu ZCBmYWxzZSBkaXNjbG9zdXJlcy4gIChsaWJlbCBhbmQgc2xhbmRlciBsYXdzKQ0KDQpBbHNvLCB0 aGVyZSBhcmUgbGVnaXRpbWF0ZSByZWFzb25zIGZvciBvbmUgcGVyc29uIHRvIGhhdmUgbWFueSBp ZGVudGl0aWVzLiAgVGhleSdyZSBsaWtlICJkb2luZyBidXNpbmVzcyBhcyIgKG9yIGQvYi9hKSBs YWJlbHMsIHRoZSBzYW1lIHdheSB0aGF0IGNvcnBvcmF0aW9ucyBoYXZlIG1hbnkgYnJhbmQgaWRl bnRpdGllcyBhbmQgbGluZXMgb2YgYnVzaW5lc3MuICBUaGUgdGhpbmcgaXMsIHRoZXNlIGV4aXN0 IGluZGVwZW5kZW50IG9mIGFueSBDQSdzIHJlY29nbml0aW9uLiAgQW55IHRpbWUgd2UgdHJ5IHRv IHBsYWNlIGEgbGltaXQgYWdhaW5zdCBiZWhhdmlvciB0aGF0IGxlZ2l0aW1hdGVseSBvY2N1cnMg aW4gdGhlIHdpbGQsIHdlJ3JlIGVuZ2FnaW5nIGluIGFuIGFjdGl2aXR5IHdoaWNoIGlzIHJlc2Vy dmVkIGZvciBsZWdpc2xhdG9ycyBhbG9uZS4NCg0KV2h5IGRvZXNuJ3QgdGhlIHNvZnR3YXJlIGlu IHRoZSB3b3JsZCB0b2RheSBwcm92aWRlIHRoaXMgY2FwYWNpdHk/ICBPaCwgdGhhdCdzIHJpZ2h0 LCBpdCdzIGJlY2F1c2UgaXQncyBhbiBhbGwtb3Itbm90aGluZyBhdG9taWMgc3RydWN0dXJlLCB5 b3UgZWl0aGVyIGFjY2VwdCBhbGwgb2YgaXQgL2FuZCBldmVyeSBzZW1hbnRpYyB0aGF0IHRoZSBh YnNvbHV0ZSBpbXBsaWNpdCB0cnVzdCBpbXBsaWVzLyBvciB5b3UgYWNjZXB0IG5vbmUgb2YgaXQu DQoNCj4gUmlnaHQgbm93LCBhbGwgdGhlIHJvb3QgY2VydHMgaW4gbXkgc3RvcmUgY2FuIGNyZWF0 ZSBjZXJ0aWZpY2F0ZXMgaW4NCj4gbW9zdCBhbnkgcmFuZ2UuIKBBIGZ1bmRhbWVudGFsIHByaW5j aXBsZSB3ZSBuZWVkIHRvIGNvbnNpZGVyIGlzIGxvY2FsDQo+IGVuZC1wb2ludCBjb25zdHJhaW50 IG9mIHRydXN0Lg0KDQpUaGUgZnVuZGFtZW50YWwgcHJpbmNpcGxlIHdlIG5lZWQgdG8gY29uc2lk ZXIsIGZyb20gd2hpY2ggZGVyaXZlcyB5b3VyIHByaW5jaXBsZSwgaXMgInRoZSBvd25lciBvZiB0 aGUgbWFjaGluZSBpcyBmb3IgYWxsIHByYWN0aWNhbCBwdXJwb3NlcyBhIG1pbm9yIGRlaXR5IGlu IGEgd29ybGQgb2YgbmF0dXJhbCBhbmQgY29ycG9yYXRlIG1pbm9yIGRlaXRpZXMuIiAgQSBuYXR1 cmFsIHBlcnNvbiBhbmQgYSBjb3Jwb3JhdGUgYm9keSBhcmUgYm90aCBib2RpZXMsIGFuZCBhIG5h dHVyYWwgcGVyc29uIGhhcyBhcyBtdWNoIG5lZWQgZm9yIGFuZCByaWdodCB0byBjb250cm9sIG92 ZXIgaGlzIG93biB3b3JsZCBhcyBhIGNvcnBvcmF0aW9uIGhhcyBmb3IgaXRzLiAgQm90aCBvZiB0 aGVzZSB0eXBlcyBvZiBtaW5vciBkZWl0aWVzIGNhbiBiZSBoZWxkIGFjY291bnRhYmxlIGJ5IHRo ZSBncmVhdGVyIGRlaXRpZXMgKHRoZSB0aGluZ3Mgd2UgY2FsbCAnc3RhdGVzJykuDQoNCkkgY2Fu J3QgaG9sZCB5b3UgYWNjb3VudGFibGUuICBJIGNhbiBhc2sgdGhlIHN0YXRlIHRvIGhvbGQgeW91 IGFjY291bnRhYmxlLCBidXQgSSBjYW5ub3QgZGlyZWN0bHkgdmlvbGF0ZSBhbnkgcmlnaHQgb2Yg eW91cnMuICBJZiBJIGRvLCB5b3UgY2FuIGFzayB0aGUgc3RhdGUgdG8gaG9sZCBtZSBhY2NvdW50 YWJsZS4gIEV2ZW4gaWYgSSdtIGhpcmVkIGJ5IHRoZSBzdGF0ZSBhbmQgaGF2ZSBzb21lIG1lYXN1 cmUgb2YgYXV0aG9yaXR5IHRvIG15IHdvcmssIEkgYWxzbyBjYW5ub3Qgc2ltcGx5IGJhcmdlIGlu IGFuZCB2aW9sYXRlIHlvdXIgcmlnaHRzLiAgRm9yIG91ciBwdXJwb3NlcywgeW91IGFyZSBhIHNv dmVyZWduLCBhIGxhdy1tYWtpbmcgYXV0aG9yaXR5IG92ZXIgeW91ciBvd24gYWZmYWlycywgYW5k IEkgaGF2ZSBubyBqdXJpc2RpY3Rpb24gdGhlcmUuICBJRVRGIGhhcyBubyBqdXJpc2RpY3Rpb24g dGhlcmUuICBZb3UgY2FuIHZpb2xhdGUgcmZjMjgwNCBhbGwgeW91IGxpa2UsIGFuZCBJIGNhbid0 IGhvbGQgeW91IGFjY291bnRhYmxlLiAgSSBjYW4gdmlvbGF0ZSBpdCBhbGwgSSBsaWtlLCBhbmQg eW91IGNhbid0IGhvbGQgbWUgYWNjb3VudGFibGUuICBUaGlyZCBwYXJ0aWVzIGNhbiAoYW5kIGRv ISkgdmlvbGF0ZSBpdCwgYW5kIHdlIGNhbid0IGhvbGQgdGhlbSBhY2NvdW50YWJsZS4NCg0KVGhl IG9ubHkgdGhpbmcgd2UgY2FuIGRvIGlzIGNyZWF0ZSBhIG5ldyBjbGFzcyBvZiBjZXJ0aWZpY2F0 ZXM6IGZyb20gZW50aXRpZXMgdW50cnVzdGVkIHRvIHByb3ZpZGUgYXV0aG9yaXRhdGl2ZSBpZGVu dGl0eSBpbmZvcm1hdGlvbiBidXQgb3RoZXJ3aXNlIHRydXN0d29ydGh5IGZvciBzb21lIGxvY2Fs IHBvbGljeS4gIChBbmQgdG8gcHJldmVudCB0aGlzIGhhcHBlbmluZyBpbiB0aGUgZnV0dXJlLCB3 ZSBzaG91bGQgY3JlYXRlIGd1aWRhbmNlIGZvciB3aGF0IHRvIGRvIHdoZW4gYSBjaGFpbiBmcm9t IGFuIHVua25vd24gY2VydGlmaWVyIGlzIGVuY291bnRlcmVkLikNCg0KPiBJZiBJIGNvdWxkIGRv IHRoaXMgLSB0aGVuIHRoZSByYW5kb20gcm9vdCBjZXJ0IHRoYXQgSSBhY2NlcHQgZm9yDQo+IHlv dXIgc2lnbmF0dXJlIGNvdWxkIGJlIGxvY2FsbHkgY29uc3RyYWluZWQgdG8gYmUganVzdCBmb3Ig eW91IG9yDQo+IGEgc21hbGwgZG9tYWluIHJhbmdlIChlLmcuIGFuIGVudGVycHJpc2UpDQoNCkkg d2hvbGVoZWFydGVkbHkgYWdyZWUuICBXaHkgZG9lc24ndCBzb2Z0d2FyZSBhbGxvdyBmb3IgaXQ/ ICBPaCwgcmlnaHQsIGJlY2F1c2UgZXZlcnl0aGluZyBpcyBiaW5hcnkgaW4gdGhlIHNvZnR3YXJl IGFuZCB0aGVyZSdzIG5vIHdheSB0byBwYXRjaCBhbGwgb2YgdGhlIGJpbmFyeSBkZWNpc2lvbnMg dG9nZXRoZXIgYmVjYXVzZSBldmVyeSBkZWNpc2lvbiBpcyBvbmUgZGVjaXNpb24uDQoNCj4+PiBL ZWVwaW5nIHJmYzI4MDQgaW4gbWluZCwgd2hlbiBmaXhpbmcgdGhlIHdlYWtuZXNzZXMgaW4gdGhl IHRydXN0IG1vZGVsDQo+Pj4gb2YgVExTLCBtYWludGFpbmluZyB3aXJldGFwcGluZyBjYXBhYmls aXRpZXMgaXMgKk5PVCogYXBwcm9wcmlhdGUuDQo+DQo+IFllcyEgoEV4Y2VsbGVudCByZmMyODA0 IHN0YXRlbWVudC9wb3NpdGlvbiBhbmQgYSBnb29kIGZvdW5kYXRpb24NCj4gdG8gbm90IGRlc2ln biBpbiBNSVRNcy4NCg0KVGhlIHByb2JsZW0gaXMsIElFVEYgY2Fubm90IGFmZm9yZCB0aGUgcHN5 Y2hvc2lzIG9mIHVuYWNrbm93bGVkZ2VkIHJlYWxpdHkuICBJdCB3aWxsIGhhcHBlbiBubyBtYXR0 ZXIgd2hhdCB3ZSBkbywgd3JpdGUsIG9yIHNheS4gIFRoZXJlIGRvIGV4aXN0IChjb250cmFyeSB0 byBwb3B1bGFyIGJlbGllZikgZ29vZCByZWFzb25zIGZvciBpdCBoYXBwZW5pbmcuICBQZW9wbGUg d2lsbCBhbHdheXMgZGVtYW5kIHRoZSBjYXBhY2l0eSwgbm8gbWF0dGVyIHdoYXQgd2UgdGhpbmsg c2hvdWxkIGJlIHJpZ2h0IG9yIGxlZ2l0aW1hdGUgb3IgbGVnYWwsIGJlY2F1c2Ugb3VyIGF0dGVt cHQgdG8gbWFuZGF0ZSBpdCBpcyBub3QgbGVnYWwgb3IgbGVnaXRpbWF0ZSBvciByaWdodC4NCg0K Pj5JIHRoaW5rIGl0J3MgaW5jcmVkaWJseSBuYWl2ZSB0byBhZGhlcmUgdG8gdGhlIGRpcmVjdGlv bnMgYW5kIGRlbWFuZHMgb2YNCj4+YSBkb2N1bWVudCBjcmVhdGVkIG9uIHRoZSBjdXNwIG9mIGEg dGVjaG5vbG9neSB3aGljaCBzdWRkZW5seSBoYWQgYSBtdWNoDQo+PmJyb2FkZXIgcG90ZW50aWFs IHRoYW4gaGFkIGV2ZXIgYmVlbiBjb25zaWRlcmVkIGJlZm9yZS4goFdlJ3ZlIGdvdCB0aGUNCj4+ TGF3IG9mIERlcGxveW1lbnQgSW5lcnRpYSBhZ2FpbnN0IHVzOiBpZiB3ZSB0cnkgdG8gY3JlYXRl IHNvbWV0aGluZw0KPj53aGljaCBicmVha3MgY29tcGF0aWJpbGl0eSB3aXRoIGV4aXN0aW5nIHN5 c3RlbXMsIG5vYm9keSB3aWxsIHVwZ3JhZGUuDQo+DQo+IEh1aD8goE1JVE1zIGFyZSBiYWQgYXMg YSBkZXNpZ24gcmVxdWlyZW1lbnQuIKBUaGV5IGFyZSBlYXN5IHRvIGNyZWF0ZQ0KPiBpZiB5b3Ug d2FudCAtIGdvIGFoZWFkLCBidXQgbm90IGFzIGEgY29yZSBhcmNoaXRlY3R1cmFsIHByaW5jaXBs ZS4NCg0KUGVyaGFwcyBJJ20gdGFraW5nIHRvbyBtdWNoIGZyb20gdGhlICJoYXJtIHJlZHVjdGlv biIgbG9iYnksIGJ1dC4uLiBpZiB3ZSBkb24ndCBwbGFuIGZvciB0aGVtLCB0aGV5J3JlIHNpbXBs eSBnb2luZyB0byBkbyBhbm90aGVyIGVuZCBydW4gYXJvdW5kIHRoZSBlbmQtdG8tZW5kIGd1YXJh bnRlZXMgd2UgdHJ5IHRvIG1ha2UgaW4gdGhpcyBlZmZvcnQuICBXZSB3aWxsIGhhdmUgYXMgbGl0 dGxlIGNvbnRyb2wgb3ZlciB0aGUgcHJvY2VzcyBhdCB0aGF0IHRpbWUgYXMgd2UgZG8gbm93LiAg T3V0bGF3aW5nIHRoZW0gd2lsbCBvbmx5IGNvbnRpbnVlIHRoZSBhcm1zIHJhY2UuDQoNClBlcmhh cHMgSSBjYW4gZHJhdyBhbiBhbmFsb2d5OiBJZiB5b3UgaGlyZWQgc29tZW9uZSB0byBmaWd1cmUg b3V0IGhvdyB0byByZWR1Y2UgdGhlIGRhbWFnZSBpbiBhY2NpZGVudHMgZG9uZSBvbiB5b3VyIGNp dHkgc3RyZWV0cywgYW5kIHRoYXQgc29tZW9uZSBjYW1lIGJhY2sgd2l0aCBhIHJlY29tbWVuZGF0 aW9uICJiYW4gYXV0b21vYmlsZXMgb24gdGhlIHN0cmVldHMiLCB5b3Ugd291bGRuJ3QgYmUgaGFw cHkuICBJZiBoZSBjYW1lIGJhY2sgd2l0aCAiZXZlcnlvbmUgbXVzdCBkcml2ZSBhIDE5MTIgRm9y ZCBNb2RlbCBUIiwgeW91IHdvdWxkbid0IGJlIGhhcHB5LiAgUGVyaGFwcyBvbmUgbWlnaHQgYmUg aGFwcHkgaWYgaGUgY2FtZSBiYWNrIHdpdGggImV2ZXJ5b25lIG11c3QgZHJpdmUgYSAxOTUwcy1l cmEgbXVzY2xlIGNhciwiIGJ1dCB0aGF0IHdvdWxkIGJlIGNvdW50ZXJwcm9kdWN0aXZlLiAgVGhh dCdzIHByZXR0eSBtdWNoIHdoYXQgdGhlIEludGVybmV0IGhhcyBkb25lIHdpdGggdXMsIGFuZCB3 aGF0IHdlJ3ZlIHRvIHRoaXMgcG9pbnQgZ2l2ZW4gdGhlbS4NCg0KSWYgd2UgYWxsb3cgZm9yIGl0 IHdpdGggY2xlYXIgdXNlci1pbnRlcmZhY2UgZ3VkZWxpbmVzLCB3ZSBtYWtlIGl0IGxlc3MgZGVz aXJhYmxlIGZvciB0aGUgYWN0dWFsIG93bmVycyB0byBzcGVuZCB0aGUgdGltZSByZWNvbXBpbGlu ZyB0aGVpciBzb2Z0d2FyZSB0byBtYWtlIHRoZWlyIG93biByb290cyBhcHBlYXIgZ3JlZW4gb3Ig Ymx1ZS4gIChJbiBmYWN0LCByaWdodCBub3csIHRoZXkgYWx3YXlzIGFwcGVhciBibHVlIHRoZSBz YW1lIHdheSB0aGF0IERWL09WIGNlcnRpZmljYXRlcyBkbywgd2hpY2ggaXMgdGhlIHByaW1lIHJl YXNvbiBpdCBkb2VzIHZpb2xhdGUgdGhlIGVuZC10by1lbmQgZ3VhcmFudGVlLikgIElmIHdlIGFs bG93IGZvciB0aGVtLCB3ZSBkaW1pbmlzaCB0aGUgcmV0dXJucyBhdmFpbGFibGUgdG8gdGhlIG93 bmVycyBpbiBkb2luZyBzdWNoLiAgQWxsIHdlIG5lZWQgaXMgZm9yIHVzIHRvIGltcGxlbWVudCBv dXIgc29mdHdhcmUgc28gdGhhdCBpdCB3b24ndCB0aHJvdyBhIGhpc3N5IGZpdCBpZiBpdCdzIHBy ZXNlbnRlZCB3aXRoIHNvbWV0aGluZyBmcm9tIG9uZSBvZiB0aGVzZSBzdWItdHJ1c3R3b3J0aHkg YXV0aG9yaXRpZXMsIGFuZCBhbGwgdGhhdCByZWxpZXMgb24gaXMgY2xlYXIgZ3VpZGFuY2UgKGlu IHRoZSBzYW1lIG1hbm5lciBhcyB0aGUgQ0EvQnJvd3NlciBGb3J1bSdzIEVWIGdyZWVuIGJhciBn dWlkYW5jZSkgZm9yIHdoYXQgdG8gZG8gd2hlbiBzb21ldGhpbmcgb3VyIG5hcnJvdyBtaW5kcyBj YW4ndCBjb25jZWl2ZSBpcyBjb3JyZWN0Lg0KDQpSZWFsbHksIHdobyBpcyB0aGUgSUVURiB0byB0 ZWxsIGFueSB1c2VyIG9yIGltcGxlbWVudG9yIHdoYXQgaGUgY2FuIG9yIGNhbid0IGRvPyAgVGhl IHNoZWVyIGNvbmNlaXQgaXMgYXBwYWxsaW5nLg0KDQotS3lsZSBIDQo= --gmsm1.9.5eqgynyntk2vfn4y71i1e2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTUwNjA5MjVaMCMGCSqGSIb3DQEJBDEWBBR7ChL7NAMsvDy2zCcVOdvf 9cSlfzBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAB7j2uvE0TPEuYQdtAn0BLk2wPrAHpl7YY/8Mqvq3YdL5ATIDIJN1qGRDW9VJ/Z7J3u22 Usog7Q1OHD2X5Oa03yvcVt6x8D8JWsCTGqeosHPjisaKbAuwOw32QepEkj/FXDqN2oVZ3dxpEKtm Yidb6NMfZTao81tE5vJ9X9wWH3DyO3cTlpQAv9O9oC+otQ5SE0+Tn4xnC1h5EcCbIJHsYwBYlfJo XkfpmnJrFPEijw8ElWncLlmb4A4rPWQ0ouysiw51F8AqTtqSbV1WgcQrkJ8KPoBFVOJ5eXPfjVeU ydXeVqG3gznO1CVFDYnjp2IYL+UCxWKS154gNI+13414nAAAAAAAAA== --gmsm1.9.5eqgynyntk2vfn4y71i1e2-- From olaf@NLnetLabs.nl Wed Feb 15 08:06:32 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA1121F8744 for ; Wed, 15 Feb 2012 08:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm3rL1PDHInl for ; Wed, 15 Feb 2012 08:06:27 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BF421F8742 for ; Wed, 15 Feb 2012 08:06:26 -0800 (PST) Received: from [IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14] ([IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q1FG6ENc033431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Feb 2012 17:06:14 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1329321980; bh=sfTgsPG59+ycXKMpls37ptOooZ6kHhNp+yIIJi0qUoM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=hygS9d+LoQAepBZMfA0YFluDJIHOXYLYJ3eMRKz0ETmPP8M3FQIK2C6QaMOGyHdk6 JNGpOUUT1PMT1pZ5aiVngypWDuSURISY84EfWtatgLnIJso8BP+ylUv7FFObYMAixD nWsxpxiuf+IzLy6oj6sDQDElkOMN9VNA381xsmbc= Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_02E68E83-69B1-49D2-B5AC-A26E980E3B0A"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Olaf Kolkman In-Reply-To: Date: Wed, 15 Feb 2012 17:06:08 +0100 Message-Id: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1257) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Wed, 15 Feb 2012 17:06:16 +0100 (CET) Cc: Nico Williams , "therightkey@ietf.org" , Kyle Hamilton , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 16:06:32 -0000 --Apple-Mail=_02E68E83-69B1-49D2-B5AC-A26E980E3B0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 9, 2012, at 2:16 PM, Phillip Hallam-Baker wrote: > For Alice and Bob there are many possible paths: >=20 > I very often start writing an email message on one machine and > continue on another. In the course of a typical day I use a minimum of > one PC, one Macbook, one iPhone and my work iPad. So for me it is > actually quite usual for me to start writing an email on the Mac and > continue on the PC. I typically read the messages on whichever one of > the four machines is close at hand. >=20 > So the arity of the relationships is: >=20 > MUA -> MTA: Many -> 1 > MTA -> MTA: 1 -> 1 > MTA -> MUA: 1-> Many >=20 > Now a good email setup should of course have multiple MTAs. But they > should have a setup that makes them look like a single logical unit. > There are many mail servers for example.com but only one logical mail > service. >=20 > So now we see why security policy driven by MUA published security > policy is going to fail: there is no consistency in the MUA loop. I > read mail on four separate devices. They have no way to communicate > between themselves to negotiate a common security policy and I > certainly would not want them to. >=20 > Conclusion: >=20 > 1) Security policy is a property of MTAs and not MUAs and hence of > domains and not accounts. I am wading through the list trying to catch up... and something in the = above makes me wonder. You start of with Alice and Bob, describe a relation between machinery, = and conclude that the security policy is a property of the machinery. Why is the security policy not tied to Alice and Bob? --Olaf ________________________________________________________=20 Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ =20 --Apple-Mail=_02E68E83-69B1-49D2-B5AC-A26E980E3B0A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJPO9fwAAoJEFRqER47aqpkhN8P/2wmVNzVf2/QqQgU9nR5kQXU cJexchkso4QnnV3WFOfcWhqVr0XA4OMUrKQ5NAqEa3L9NhI2S4GY/+ZQL885kIXO C5tkm7xwEkZUFniHhX3q3cOtG2x2r3sQhIe9MJuuI5nOK5Op4X4fNfaC3V24z1QI 8rmHhATG/6MPBdHogAP5Io8Ux/q6uc9fP9UVcquo9jz7uE8MeCWow87vsQ5XEYeg IjbuuoTJ9YmtLZr44XE2ztwcDO2pgAvVsWBcRhofM6sAPJilFbE63c0M6YscEJrm fcWrqBzSLeNAWo2sqsfh2Unc8PfAPYl9pWT0arlSVd/3LthdfQ+bMWiZDEE+Irvn r9ZLwO/HzqhyfVPi3Xeg5AEByherjpNtabme31bWtZlgvlr9Rp7RE6jgTqo3t/cw kVTwnDEMcLJbef8XDB+VpwPWD+sX+nchHpwn6Q4QH2xT01IU1EZ/UxedabMl0drQ 5BdJWuPzkLhK//vpG8nmNkVJJb1C8pNxJ1dhEFocWmTVug4ldQxtehmTV5HO7HOl SPrRW0lP58AnuBJscodVyizTAaKpyrQaD2uE6ISMRUzuw38X9dvMVZAOP3+Agew0 zkkqhYvdBMSx2omjQ6E4tTYz+w97kEazlmNiaUgnTLDpNPwcEM7OBjRn0T/oVWp6 GCcNRRaETzyo2IQDyY52 =Krte -----END PGP SIGNATURE----- --Apple-Mail=_02E68E83-69B1-49D2-B5AC-A26E980E3B0A-- From hallam@gmail.com Wed Feb 15 11:08:59 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C49921E806A for ; Wed, 15 Feb 2012 11:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VfGhcmMpUoL for ; Wed, 15 Feb 2012 11:08:55 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 340B421E8032 for ; Wed, 15 Feb 2012 11:08:55 -0800 (PST) Received: by qafi29 with SMTP id i29so3400526qaf.10 for ; Wed, 15 Feb 2012 11:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=r9raO61UxUjhto02Dxs4wB3XlzGtBkNKTm4DJNkPjvw=; b=pxNjA3qyN1uJWM3RpjT5E7kmoxedBhPUA+a5AFdf6rrdrmrp1Yffh25pt2ybBg1CL9 8q08+0AJhl7b+6Y6r90ChPcyUWuTjaEQ4WPnonAqk/w1QHod08bEjREQWMi1c7XA9ye2 0Rj+w4g2doDVS9MZCxFkdZlZH5Qaryp0oNBLM= Received: by 10.229.136.130 with SMTP id r2mr10095059qct.60.1329332934321; Wed, 15 Feb 2012 11:08:54 -0800 (PST) Received: from [10.0.1.22] (c-66-30-5-63.hsd1.ma.comcast.net. [66.30.5.63]) by mx.google.com with ESMTPS id o8sm12376545qan.11.2012.02.15.11.08.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 11:08:53 -0800 (PST) References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <01FCD737-1505-4AD9-8DCA-4CEEFD5FE946@gmail.com> X-Mailer: iPad Mail (9A405) From: Phillip Hallam-Baker Date: Wed, 15 Feb 2012 14:08:54 -0500 To: Olaf Kolkman Cc: Nico Williams , "therightkey@ietf.org" , Kyle Hamilton , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problems, itis her employer decides. X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 19:08:59 -0000 Yes, the policy has to come either from Alice or Alice's employer depending o= n the context. If Alice is at home, she choses, but if she is at work dealli= ng with work issues, her employer should decide. This is why i think policy should ultimately tie one to oneto DNS names: the= y are cheap and easy to obtain. If you are tied to someones dns name you are= in their power anyway. That is why i own hallambaker.com. But regardless of who is setting that policy, there has to be a single contr= ol point or it is not going to be practical. I have 48 ip enabled devices in= my house. And in the future that wont be unusual. My car has 3 separate rs4= 22 networks with 60 devices.=20 The end to end argument is not obsolete: complexity really matters. What has= changed is the conclusion. In 1970 the endpoint was the place to put comple= xity. Forty years later, a bump in the wire contolled by the policy maker is= better. Sent from my iPad On Feb 15, 2012, at 11:06, Olaf Kolkman wrote: >=20 > On Feb 9, 2012, at 2:16 PM, Phillip Hallam-Baker wrote: >=20 >> For Alice and Bob there are many possible paths: >>=20 >> I very often start writing an email message on one machine and >> continue on another. In the course of a typical day I use a minimum of >> one PC, one Macbook, one iPhone and my work iPad. So for me it is >> actually quite usual for me to start writing an email on the Mac and >> continue on the PC. I typically read the messages on whichever one of >> the four machines is close at hand. >>=20 >> So the arity of the relationships is: >>=20 >> MUA -> MTA: Many -> 1 >> MTA -> MTA: 1 -> 1 >> MTA -> MUA: 1-> Many >>=20 >> Now a good email setup should of course have multiple MTAs. But they >> should have a setup that makes them look like a single logical unit. >> There are many mail servers for example.com but only one logical mail >> service. >>=20 >> So now we see why security policy driven by MUA published security >> policy is going to fail: there is no consistency in the MUA loop. I >> read mail on four separate devices. They have no way to communicate >> between themselves to negotiate a common security policy and I >> certainly would not want them to. >>=20 >> Conclusion: >>=20 >> 1) Security policy is a property of MTAs and not MUAs and hence of >> domains and not accounts. >=20 >=20 > I am wading through the list trying to catch up... and something in the ab= ove makes me wonder. >=20 > You start of with Alice and Bob, describe a relation between machinery, an= d conclude that the security policy is a property of the machinery. >=20 > Why is the security policy not tied to Alice and Bob? >=20 >=20 > --Olaf >=20 >=20 > ________________________________________________________=20 >=20 > Olaf M. Kolkman NLnet Labs > http://www.nlnetlabs.nl/ >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From stephen.farrell@cs.tcd.ie Wed Feb 15 11:17:48 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253D121F853D for ; Wed, 15 Feb 2012 11:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL9gojylytvl for ; Wed, 15 Feb 2012 11:17:35 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A53E21F84F6 for ; Wed, 15 Feb 2012 11:17:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E3383171E1E for ; Wed, 15 Feb 2012 19:17:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1329333448; bh=I1u7S987OoDf/NYLPN30ED7P LZwi+8cdYmDkedkrIng=; b=J1nIJHeMYgbYJado46+BjC1faaaQSUNtaWqQuM5h RVfIApWtpv9VLParaWTclzFaLHdbv5q7WnXZWmDpFf1dk/iWlLzauU6f2RBjejBj frcjCGXOkgKfdYaljFWI1PT3zzn37IxE1Edzy8jwfzWla4CiL4/A84ItKHbM825E Zn4nWUQr3bKeYNbnIJyqKzghqqEnIt5fPQjCpV3Edwey+AXkJFmRFbhv83xQgLtP GIdowA8eA9+Bn/jno5umdFigzFeC+Hii+CiP+720OjbONHozjUzNF7SqUObbRefb 0jUf+qot2k+z/fuOKWPqm0AyYxGNLCKsNaiuem7OkAgtWg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id YScSFJd1yJWi for ; Wed, 15 Feb 2012 19:17:28 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A50C9171D22 for ; Wed, 15 Feb 2012 19:17:28 +0000 (GMT) Message-ID: <4F3C04C9.7040601@cs.tcd.ie> Date: Wed, 15 Feb 2012 19:17:29 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: "therightkey@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 19:17:48 -0000 Hiya, I guess the recent publications about common factors [1,2] are something else that this group might want to consider. I wonder if an rsa modulus checker protocol might help or something. Not sure if that's something that could be run quickly enough though, other than for the straight duplicates or dumbass things with small factors you should spot yourself. Anyone know? Or maybe you could register your public key and get a nonce, then come back periodically to see if any problems have been detected for your key. And yes, better prngs are needed, but there'll probably always be bad ones out there. S. [1] http://eprint.iacr.org/2012/064 [2] http://it.slashdot.org/story/12/02/15/1540212/factorable-keys-twice-as-many-but-half-as-bad From paul@marvell.com Wed Feb 15 12:30:50 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0747921F85A0 for ; Wed, 15 Feb 2012 12:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciGQ7DMcr4nY for ; Wed, 15 Feb 2012 12:30:49 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id 33DBF21F858F for ; Wed, 15 Feb 2012 12:30:49 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTzwV7CO+yt/faxCqfqGhm+FGoePIzVTg@postini.com; Wed, 15 Feb 2012 12:30:49 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Wed, 15 Feb 2012 12:28:09 -0800 From: Paul Lambert To: Carl Wallace Date: Wed, 15 Feb 2012 12:28:09 -0800 Thread-Topic: [therightkey] Basically, it's about keeping the CAs honest Thread-Index: AczrkCHb2Au+AhPsQHGhika2vUpaTQAgRx8g Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579DA1693@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01579DA14D8@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 20:30:50 -0000 >>If I could do this - then the random root cert that I accept for >>your signature could be locally constrained to be just for you or >>a small domain range (e.g. an enterprise) > >Yep. There are specs that enable this (RFCs 5914 and 5937) but they are >not in wide use. Thanks. Appreciate the pointers. Providing an explicit limitation of trust is an important design requirement. A well thought out design, but the complexity may be limiting adoption. Then again - the complexity is a function of the core 509 framework ... if trust expressions were easier to express would there be better adoption and more trustworthy implementations? Paul From aerowolf@gmail.com Wed Feb 15 16:57:31 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3517721E800E for ; Wed, 15 Feb 2012 16:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYdU-mOzlcxI for ; Wed, 15 Feb 2012 16:57:26 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C817A21F847C for ; Wed, 15 Feb 2012 16:57:26 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2030100pbc.31 for ; Wed, 15 Feb 2012 16:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:mime-version:content-type; bh=Nrr/qZIWkJveZqA6OtfA1jIFX1M2I519x4E+UY9HcoU=; b=Sy9w+byj8rVhWHeDNtDRzAOWWKMfPsGSC4cLB/1kg/7RrLKEo1wl8W+bwGV3fdU3w5 JYkiMu5JX1NL2kFdEJCkLCSU9BPyjSHvL2nVS4kCEJvRYbFpUvYHS6OwwVv/04wkuA6H TfXw2nk2t3EF/7fe9JeAonKoZPl7wSLlruK9o= Received: by 10.68.72.70 with SMTP id b6mr8355177pbv.58.1329353845098; Wed, 15 Feb 2012 16:57:25 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id e8sm805251pbg.47.2012.02.15.16.57.20 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 16:57:22 -0800 (PST) From: "Kyle Hamilton" To: "Phillip Hallam-Baker" Date: Wed, 15 Feb 2012 16:57:22 -0800 (Pacific Standard Time) Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgyp2ydh5cccffr1vkh2 Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 00:57:31 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgyp2ydh5cccffr1vkh2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Q29tbWVudHMgaW5saW5lLg0KDQpPbiBXZWQsIEZlYiA4LCAyMDEyIGF0IDg6MTQgUE0sIFBoaWxs aXAgSGFsbGFtLUJha2VyIDxoYWxsYW1AZ21haWwuY29tPiB3cm90ZToNCj4gMSkgVGhlcmUgaXMg bm8gbWVhbnMgZm9yIGEgcmVjaXBpZW50IHRvIGV4cHJlc3MgaXRzIHNlY3VyaXR5IHBvbGljeS4N Cg0KTW9yZSBpbXBvcnRhbnRseSwgdGhlcmUncyBubyBjdXJyZW50IGJhc2lzIGZvciBhY3Rpb24g aWYgdGhlIGNsaWVudCdzIHNlY3VyaXR5IHBvbGljeSBpcyB2aW9sYXRlZCBieSB0aGUgc2VydmVy LiAgQ29tbXVuaWNhdGluZyBpdCBpcyBhbGwgd2VsbCBhbmQgZ29vZCwgYnV0IHRoZSBzZXJ2ZXIg aXMgYSBwZWVyIGFuZCBjYW4ndCBiZSBmb3JjZWQgdG8gZm9sbG93IGl0IGlmIHRoZXJlJ3Mgbm8g dGVldGggdG8gaXQuDQoNCk91ciB0ZWNobm9sb2dpZXMgc2hvdWxkIHBlcm1pdCB0aGUgd29ybGQg dG8gZ3JvdyBhbmQgZXZvbHZlIG1vcmUgZWZmZWN0aXZlbHkuICBSaWdodCBub3csIHRoZXkgZG8g bm90aGluZyBidXQgaGFtcGVyIGl0LiAgV2h5IGhhdmVuJ3Qgd2UgY3JlYXRlZCBhbnl0aGluZyB0 byBhbGxvdyBvdXIgdXNlcnMgdG8gbGV2ZXJhZ2UgZXhpc3RpbmcgbGF3IHRvIGVuZm9yY2UgdGhl aXIgcG9saWNpZXM/DQoNCj4gMikgVGhlcmUgaXMgbm8gaW5mcmFzdHJ1Y3R1cmUgdG8gYWxsb3cg c2VuZGVycyB0byBldmFsdWF0ZSBleHByZXNzaW9ucw0KPiBvZiBzZWN1cml0eSBwb2xpY3kgYW5k IGNvbWUgdG8gYSB1c2VmdWwgZGVjaXNpb24gb24gd2hldGhlciBvciBob3cNCj4gdGhleSBzaG91 bGQgYmUgZW5mb3JjZWQuDQoNCkV4cHJlc3Npb24gb2Ygc2VjdXJpdHkgcG9saWN5OiAiSSB3aWxs IG5vdCBjb25uZWN0IG9uIHBvcnQgODAuIiAgU2ltcGxlIGFuZCB0byB0aGUgcG9pbnQuDQoNClVu Zm9ydHVuYXRlbHksIGl0J3MgbmV2ZXIgZ29pbmcgdG8gYmUgYWJsZSB0byBoYXBwZW4gb24gdGhp cyBJbnRlcm5ldCBhcyBsb25nIGFzIHRoZSBjZXJ0aWZpY2F0aW9uLWF1dGhlbnRpY2F0aW9uIG1v ZGVsIGlzIGJyb2tlbi4NCg0KPiBMZXRzIGdldCBhd2F5IGZyb20gdGhlIGRldGFpbHMgb2YgaG93 IHRoZSBzZWN1cml0eSBwb2xpY3kgaXMNCj4gZXhwcmVzc2VkLiBUaGUgY29yZSBtaXNzaW5nIGNv bXBvbmVudCBpbiBTTUlNRSBpcyB0aGF0IGEgc2VuZGVyIGRvZXMNCj4gbm90IGtub3cgd2hldGhl ciBvciBub3QgdG8gdXNlIGVuY3J5cHRpb24gd2hlbiBzZW5kaW5nIGEgbWVzc2FnZS4NCg0KVGhp cyBpcyBvbmx5IHRydWUgaW4gdGhlIFNwZWNpYWwgQ2FzZSBvZiAibm8gcHJpb3IgY29tbXVuaWNh dGlvbiIuICBBIHNlbmRlciBrbm93cyB3aGV0aGVyIHRvIHVzZSBlbmNyeXB0aW9uIGFzIHNvb24g YXMgaGUgaGFzIGluZm9ybWF0aW9uIGFib3V0IHRoZSByZW1vdGUncyBhYmlsaXR5IHRvIGhhbmRs ZSBpdCwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGhlIGhhcyBhIGNlcnRpZmljYXRlLiAgVGhpcyBp cyB3aHkgYSBoZWFkZXIgaXMgbmVjZXNzYXJ5LCB0aGUgb25seSB3YXkgdGhhdCBTL01JTUUgY2Fw YWJpbGl0aWVzIGNhbiBiZSBleHByZXNzZWQgcmlnaHQgbm93IGlzIHRvIHNlbmQgYSBjZXJ0aWZp Y2F0ZSB3aGljaCBtdXN0IGJlIGlzc3VlZCBieSBzb21lb25lIGVsc2UgYWJvdXQgd2hhdCB5b3Vy IHNvZnR3YXJlIGlzIGNhcGFibGUgb2YgZG9pbmcgcmlnaHQgbm93Lg0KDQpVbmxlc3Mgd2Ugc3Rh cnQgYWxsb3dpbmcgc2VsZi1zaWduZWQgUy9NSU1FIGNlcnRpZmljYXRlcyAod2hpY2ggaXMgYSBj b21wbGV0ZWx5IGRpZmZlcmVudCBtYXR0ZXIpIG9yIGJhcmUgU1BLSSAoYSBiaXQgbGVzcyB1c2Vm dWwpLCB0aGUgb25seSB3YXkgdG8ga2VlcCB0aGUgcGVvcGxlIGFjdHVhbGx5IGludm9sdmVkIGlu IHRoZSBjb21tdW5pY2F0aW9uIGl0c2VsZiBpbiBzeW5jIHdpdGggdGhlaXIgc29mdHdhcmUncyBj YXBhYmlsaXRpZXMgaXMgdG8gYWxsb3cgdGhlIGluaXRpYWwgc2lnbmVkIGNvbW11bmljYXRpb24g aXRzZWxmIHRvIGNvbnRhaW4gaW5mb3JtYXRpb24gb24gdGhlIGRlc2lyZWQgc2VjdXJpdHkgcGFy YW1ldGVycy4NCg0KVGhlICJsb29raW5nIGZvciB0aGUgcmlnaHQga2V5IiBib290c3RyYXAgcHJv YmxlbSBpcyBiZWluZyBtYWRlIGludG8gc28gbXVjaCBvZiBhIG1vdW50YWluIHRoYXQgIndoYXQg ZG8gd2UgZG8gd2l0aCB0aGUgcmlnaHQga2V5PyIgaGFzIGZhbGxlbiBieSB0aGUgd2F5c2lkZS4g IFVudGlsIHdlIGtub3cgdGhhdCwgd2hhdCBhcmUgd2UgZmlnaHRpbmcgb3Zlcj8NCg0KPiBUaGUg c2VjdXJpdHkgcG9saWN5IGNvdWxkIGJlIGV4cHJlc3NlZCBpbiBoZWFkZXJzIG9yIGVuY29kZWQg aW4gRE5TDQo+IHJlY29yZHMgb3IgdHJhbnNwb3J0ZWQgdGhyb3VnaCBvdXQgb2YgYmFuZCBtZWFu cy4gVGhlcmUgYXJlIHByb3MgYW5kDQo+IGNvbnMgdG8gZWFjaCBhcHByb2FjaCwgdGhlIHNhbWUg b25lcyB0aGF0IGNvbWUgdXAgaW4gdGhlIFRMUyBjYXNlLg0KDQpBcyBpdCBzdGFuZHMgYXQgdGhp cyBtb21lbnQsIGZvciBpbmRpdmlkdWFscyB0aGUgc2VjdXJpdHkgcG9saWN5IGlzIHRoZSBzYW1l IGV2ZXJ5d2hlcmUuICAgSXQgYWxzbyB3b3JrcyBhYm91dCBhcyB3ZWxsIGV2ZXJ5d2hlcmUgYXMg ZXZlcnl3aGVyZSBlbHNlLCB3aGljaCBpcyB0byBzYXkgIm5vdCBhdCBhbGwiLg0KDQpBcyBhIHN0 YW5kYXJkcyBib2R5LCBJIHRoaW5rIElFVEYgc2hvdWxkIHNwZWNpZnkgdGhlIHNlY3VyaXR5IGFy Y2hpdGVjdHVyZS4gIEl0IHNob3VsZCBkZWZpbmUgd2hhdCBhIGNvbXBldGVudCBwb2xpY3kgc2hv dWxkIGFkZHJlc3MsIGl0IHNob3VsZCBkZWZpbmUgdGhlIHBsYWNlcyB3aGVyZSBwb2xpY3kgY2Fu IGJlIGFwcGxpZWQsIGFuZCBpdCBzaG91bGQgZnJvbSB0aW1lIHRvIHRpbWUgZGVmaW5lIGEgbWlu aW1hbCBwb2xpY3kgd2hpY2ggY29uZm9ybWFudCBpbXBsZW1lbnRhdGlvbnMgbXVzdCBiZSBhYmxl IHRvIHVzZS4gIEluIGV2ZXJ5IG90aGVyIHJlc3BlY3QsIHBvbGljeSBwcm9jZXNzaW5nIGFuZCBw b2xpY3kgZGVjaXNpb25zIG11c3QgYmUgY29tcGxldGVseSB1cCB0byB0aGUgcGVlciBpbnZvbHZl ZC4NCg0KPiBTbyB3aGF0IEkgd291bGQgbGlrZSBpcyBhIHBvbGljeSBsYW5ndWFnZSB0aGF0IGFs bG93cyBleHByZXNzaW9ucyBvZiB0aGUgZm9ybToNCj4NCj4gZXhhbXBsZS5jb20gWVlZICJwYXRo PXdvcWlvaXFvaTJqcTNyb2kyanF3b2lqMnE9PTsgeHh4PV9odHRwLF9zbXRwIg0KPiBfaHR0cC5l eGFtcGxlLmNvbSCgWFhYICJ0bHM9YWx3YXlzIg0KPiBfc210cC5leGFtcGxlLmNvbSBYWFggInRs cz1hbHdheXM7IHNtaW1lPW9mZmVyZWQiDQoNClMvTUlNRSBpcyBhIE1VQSB0aGluZywgbm90IGEg TVRBIHRoaW5nLiAgVGhpcyBtYWtlcyBpdCByYXRoZXIgZGlmZmljdWx0IHRvIHB1dCBhbiBTL01J TUUgYWR2ZXJ0aXNlbWVudCBpbiBwbGFjZS4gIChUTFMgYWR2ZXJ0aXNlbWVudCwgdGhvdWdoLCBp cyBhIGdvb2QgaWRlYS4pDQoNCj4gX3NtaW1lLmV4YW1wbGUuY29tIFhYWCAiZGlzY292ZXI9bGRh cCx4a21zIg0KDQpUaGlzIHdvcmtzIG9uIHRoZSBvZmYgY2hhbmNlIHRoYXQgZXhhbXBsZS5jb20g cnVucyBpdHMgb3duIGNlcnRpZmllciBhbmQgY2FuIHB1Ymxpc2ggaXRzIG93biBjZXJ0aWZpY2F0 ZXMuDQoNCkkgd2FudCB0byBlbmFibGUgdGhlIGNhcGFjaXR5IGZvciBkb21haW4gb3duZXJzIHRv IGlzc3VlIFMvTUlNRSBjZXJ0aWZpY2F0ZXMgZm9yIGVtYWlsIGFkZHJlc3NlcyB3aXRoaW4gdGhl aXIgb3duIGRvbWFpbnMsIHdpdGhvdXQgcmVxdWlyaW5nIHRoZSBkZWxlZ2F0aW9uIG9mIGFueSBr aW5kIG9mIENBIGluZnJhc3RydWN0dXJlLiAgVGhpcyBpcyBiZWNhdXNlOg0KMSkgSXQgcHJvdmlk ZXMgYSB3YXkgdG8gbGV0IGVuZC11c2VycyBwbGF5IHdpdGggdGhlIHRlY2hub2xvZ3kgd2l0aG91 dCBiZWluZyBmb3JjZWQgaW50byBhbm90aGVyIGNvbW1lcmNpYWwgY29udHJhY3Qgb2Ygd2hpY2gg dGhleSBoYXZlIG5vdCB5ZXQgYmVlbiBjb252aW5jZWQgb2YgdGhlIHZhbHVlLg0KMikgRG9tYWlu IG93bmVycyBhcmUgYXV0aG9yaXRhdGl2ZSBmb3IgdGhlIGVtYWlsIGFkZHJlc3NlcyBhbmQgdGhl IGJvZGllcyB3aGljaCBob2xkIHRoZW0uICBUaGV5IGFyZSBub3QgYXV0aG9yaXRhdGl2ZSBmb3Ig dGhlIHJlYWwtd29ybGQgaWRlbnRpdGllcyBvZiB0aGUgYm9kaWVzLCBidXQgdGhleSBhcmUgYXV0 aG9yaXRhdGl2ZSBmb3IgbWFpbCByb3V0aW5nLCB3ZWIgc2l0ZSBjb250ZW50LCBuZXR3b3JrIGlu ZnJhc3RydWN0dXJlLCBhbmQgc28gb24uICBUaGV5IGFyZSBhbHNvIGF1dGhvcml0YXRpdmUgZm9y IHRoZWlyIG93biBwb2xpY2llcy4NCjMpIERvbWFpbiBvd25lcnMgYXJlIHRoZSBiZXN0IHN1aXRl ZCB0byBkZXRlcm1pbmluZyBleGFjdGx5IHdoYXQga2luZCBvZiBzZWN1cml0eSB0aGVpciBpbmRl cGVuZGVudCBlbmRwb2ludHMgYW5kIHNlcnZpY2VzIG5lZWQgYW5kIG5lZWQgdG8gYWR2ZXJ0aXNl IHN1cHBvcnQgZm9yLg0KDQpJZiB0aGVyZSdzIGEgdHJ1ZSBuZWVkIHRvIHByZXZlbnQgdGhlIGRv bWFpbiBvd25lciBmcm9tIGlzc3VpbmcgYSBjZXJ0aWZpY2F0ZSB0byBzb21lb25lIHdobyBpcyBu b3QgbGVnaXRpbWF0ZWx5IGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBtZXNzYWdlcyBhdCB0aGF0IGVt YWlsIGFkZHJlc3MsIGEgcGVyc29uIGNhbiBnZXQgYSBrZXkgY2VydGlmaWVkIGJ5IGEgdHJ1c3R3 b3J0aHkgYXV0aG9yaXRhdGl2ZSBDQS4gIEhvd2V2ZXIsIHRoaXMgY2Fubm90IGJlIHRoZSBib290 c3RyYXAgY2FzZS4NCg0KPiBNZWFuaW5nLCBjZXJ0cyBvZmZlcmVkIGZvciBleGFtcGxlLmNvbSB3 aWxsIG9iZXkgdGhlIHNwZWNpZmllZA0KPiBjZXJ0aWZpY2F0ZSBwYXRoIGNvbnN0cmFpbnQgaWRl bnRpZnlpbmcgdGhlIGNlcnQgc2lnbmluZyBjZXJ0IGZvciB0aGUNCj4gZW50ZXJwcmlzZSBQS0ks IHRoZXJlIGFyZSBhZGRpdGlvbmFsIHBvbGljeSBzcGVjaWZpY2F0aW9ucyBmb3IgaHR0cA0KPiBh bmQgc210cCBib3RoIG9mIHdoaWNoIHNheSB0bHMgaXMgYWx3YXlzIG9mZmVyZWQsIHNtaW1lIGlz IGFsc28NCj4gYXZhaWxhYmxlIGFuZCB5b3UgY2FuIHB1bGwgdGhlIGNsaWVudCBjZXJ0IHVwIHVz aW5nIGVpdGhlciBsZGFwIG9yDQo+IHhrbXMgZGlzY292ZXJ5IHJvdXRlcy4NCg0KQWgsIHNvIHlv dSdyZSBub3QgY29uc2lkZXJpbmcgdGhlIGluZGl2aWR1YWwncyBpbml0aWFsIGNvbnRhY3Qgd2l0 aCBvdGhlciBpbmRpdmlkdWFscy4gIFlvdSdyZSBjb25zaWRlcmluZyBvbmx5IHRoZSBjYXNlIG9m IHRoZSBpbmRpdmlkdWFsJ3MgaW5pdGlhbCBjb250YWN0IHdpdGggYSBjZWxsIG9mIGEgY29ycG9y YXRlIGJvZHksIG9yIGNvcnBvcmF0ZSB0byBjb3Jwb3JhdGUgaW5pdGlhbCBjb250YWN0LiAgWW91 J3JlIG5vdCBjb25zaWRlcmluZyB0aGUgaWRlYSBvZiBpbnRyb2R1Y2VycyAocGVvcGxlIHdobyBz aGFyZSBjb250YWN0IGRldGFpbHMgd2l0aCBvdGhlcnMsIGZvciBpbml0aWFsIGNvbnRhY3Qgb25s eSksIG9yIGhvdyB0aGF0IGNhbiBsb2dpY2FsbHkgYmUgZXh0ZW5kZWQgd2l0aCBlbGVjdHJvbmlj IG1lZGlhdGlvbi4NCg0KSSBhbSBub3QgYSBmYW4gb2YgZmVkZXJhdGVkIGlkZW50aXR5IHN5c3Rl bXMgZm9yIGF1dGhvcml0YXRpdmUgaWRlbnRpdHkgaW5mb3JtYXRpb24gKG1lYW5pbmcsIGluZm9y bWF0aW9uIG1haW50YWluZWQgYnkgYSBwdWJsaWMgcmVnaXN0ZXIsIGFuZCB1c2VmdWwgaW4gYnJp bmdpbmcgdGhlIHBvd2VyIG9mIHRoZSBzdGF0ZSB0byBiZWFyKS4gIEkgYW0gYSBmYW4gb2YgZmVk ZXJhdGVkIGlkZW50aXR5IHN5c3RlbXMgZm9yIHByaXZhdGVseS11c2VmdWwgcmVwdXRhdGlvbiBp bmZvcm1hdGlvbiwgd2hlcmUgdGhhdCByZXB1dGF0aW9uIGluZm9ybWF0aW9uIGlzIGxpbmtlZCB0 byAidGhlIGhvbGRlciBvZiBhIHBhcnRpY3VsYXIga2V5Ii4NCg0KT3VyIGNvbXB1dGVycyBoYXZl IG5vIGNvbmNlcHQgb2YgaWRlbnRpdHkgb3RoZXIgdGhhbiAidGhlIHRoaW5nIHdoaWNoIHByb3Zp ZGVzIGlucHV0IHdoaWNoIGNhbiBiZSB2ZXJpZmllZCB1bmRlciB0aGVzZSBydWxlcyB3aXRoIHRo aXMga2V5Ii4gIEV2ZXJ5dGhpbmcgZWxzZSBpcyBtZXRhZGF0YSBhc3NvY2lhdGVkIHdpdGggdGhh dCBpZGVudGl0eS4NCg0KS2V5cyBhcmUgdXNlZnVsIGJvdGggaW50ZXJuYWxseSBhbmQgZXh0ZXJu YWxseS4gIFRoZXJlIGFyZSB0d28gdHlwZXMsIHRoZSAndXRpbGl0eSBrZXknIGFuZCB0aGUgJ2Nl cmVtb25pYWwga2V5Jy4gIEEgdXRpbGl0eSBrZXkgaXMgc2lnbmVkIG9yIHVzZWQgaW4gdGhlIG9y ZGluYXJ5IGV2ZXJ5ZGF5IG1hY2hpbmVyeS4gIEEgY2VyZW1vbmlhbCBrZXkgaXMgYW55IGtleSB3 aGljaCBpcyBzaWduZWQgYnkgYSBrZXkgaGVsZCBieSBzb21lb25lIGVsc2UuICBUaGlzIGluY2x1 ZGVzIGludGVybmFsIG5ldHdvcmsgYWNjZXNzIGNlcnRpZmljYXRlcyBpc3N1ZWQgdG8gZW1wbG95 ZWVzIGFuZCBwYXJ0bmVycy4gIFRoaXMgaW5jbHVkZXMgQmV0dGVyIEJ1c2luZXNzIEJ1cmVhdS4g IEl0IGluY2x1ZGVzIHZhcmlvdXMgbG9jYWxpdGllcycgY2hhbWJlcnMgb2YgY29tbWVyY2UuICBJ dCBpbmNsdWRlcyBhIHNlcnZpY2UgYWNjZXNzIGNlcnRpZmljYXRlIGlzc3VlZCBieSBhIGZvcnVt IG9wZXJhdG9yLiAgQW55dGhpbmcgd2hpY2ggaXMgdXNlZnVsIHRvIG9idGFpbiBzb21ldGhpbmcg d2hpY2ggd291bGQgbm90IGJlIG9idGFpbmFibGUgd2l0aG91dCBpdCwgc3VjaCBhcyB0cnVzdCBv ciBjb21wdXRlciBjeWNsZXMuIA0KDQpCeSBlbGV2YXRpbmcgdGhlIHNpZ25lciBvZiBldmVyeSBj ZXJlbW9uaWFsIGtleSBvZiBhbnkgdHlwZSBpbiB0aGUgVUkgdG8gcGVlcmFnZSB3aXRoIHRoZSBB dXRob3JpdGF0aXZlIElkZW50aXR5IENBLCBhbmQgc2ltcGx5IHRha2luZyBjYXJlIHRvIG5vdGUg dG8gb3VyIHVzZXIgaW50ZXJmYWNlIHdoZW4gdGhlcmUncyBhIGNoYWluIGZyb20gc29tZW9uZSB0 cnVzdGVkIHRvIHByb3ZpZGUgYXV0aG9yaXRhdGl2ZSBpZGVudGl0eSBpbmZvcm1hdGlvbiBpbiB0 aGUgY2FzZSBvZiBsZWdhbCBkaXNwdXRlLCB3ZSBjYW4gbWFrZSBjcnlwdG9ncmFwaGljIHNlY3Vy aXR5IHNvbWV0aGluZyB0aGF0IHBlb3BsZSBjYW4gYWN0dWFsbHkgdXNlLg0KDQo+IFVubGlrZSB0 aGUgdXN1YWwgY2FzZSBvZiBsb29raW5nIGF0IGEgcHJvdG9jb2wgd2hlcmUgcGVvcGxlIGluc2lz dA0KPiB0aGF0IGl0IHN1cHBvcnQgUEdQIGtleXMsIFNQS0kga2V5cyBhbmQgc2l4dGVlbiBkaWZm ZXJlbnQgcHVibGljIGtleQ0KPiBhbGdvcml0aG1zIGJlY2F1c2UgdGhleSBoYXBwZW4gdG8gbGlr ZSAnZW0sIHRoZXJlIGlzIGEgcmVhbCBzZXQgb2YNCj4gcmVxdWlyZW1lbnRzIGFuZCBhIHJlYWwg Y29uc3RpdHVlbmN5IGZvciBzZWN1cmUgU01UUC4gQW5kIFNNVFAgd2FzIHRoZQ0KPiBvdGhlciBr aWxsZXIgYXBwbGljYXRpb24gZm9yIHRoZSBJbnRlcm5ldCBiZXNpZGVzIHRoZSBXZWIuDQoNCklu c3RlYWQgb2YgZ2V0dGluZyBodW5nIHVwIG9uIHRoYXQsIHdoeSBkb24ndCB3ZSBqdXN0IGNyZWF0 ZSBwcm90b2NvbHMgdGhhdCBoYW5kbGUgYWJzdHJhY3QgdHlwZXMgYW5kIGZvcm1hdHMgb2YgYXV0 aG9yaXRpZXMsIHdpdGggYSBjcmVkZW50aWFsIHR5cGUgZmllbGQ/ICAoWW91IGtub3csIGxpa2Ug dGhlIHVzZSBvZiBPSURzIHRvIGlkZW50aWZ5IHRoZSB0eXBlIG9mIGFuIFNQS0kgb3Igc2lnbmF0 dXJlIGFsZ29yaXRobSwgb3IgdGhlIFRMUyBhdXRoX3R5cGUgZXh0ZW5zaW9uPykNCg0KPiBUaGUg cHJvYmxlbSB3aXRoIGp1c3QgaGF2aW5nIHNlY3VyaXR5IHBvbGljeSBvcmlnaW5hdGlvbiBpcyB0 aGF0IHJhdw0KPiBzZWN1cml0eSBwb2xpY3kgc3RhdGVtZW50cyB0ZW5kIHRvIGhhdmUgYSBtdWNo IGhpZ2hlciBlcnJvciByYXRlIHRoYW4NCj4gaXMgZ2VuZXJhbGx5IHRvbGVyYWJsZS4gUGFydGlj dWxhcmx5IGR1cmluZyB0aGUgaW50cm9kdWN0b3J5IHBoYXNlDQo+IHdoZW4gdGhlcmUgaXMgbGl0 dGxlIHJlbHlpbmcgaW5mcmFzdHJ1Y3R1cmUuDQoNClRoaXMgaXMgd2h5IHRoZSBkZWZhdWx0IGNh c2UgbXVzdCBiZSB0byBlbmFibGUgc2VjdXJpdHkgd2l0aG91dCByZXF1aXJpbmcgY2VydGlmaWNh dGlvbiBmcm9tIGEgJ3RydXN0d29ydGh5JyBhdXRob3JpdHkuICBHZXQgdGhlIHRlY2hub2xvZ3kg d29ya2luZyBmaXJzdCwgdGhlbiBhZGQgdGhlIGNlcnRpZmljYXRpb24gbGF5ZXIgYXMgYSBtZWFu cyBvZiBpbXByb3ZpbmcgaXQuDQoNCj4gU28gZXZlbiB0aG91Z2ggZW1haWwgc2VydmVycyBjYW4g aW4gdGhlb3J5IHNpbXBseSBwdWxsIHVwIHJhdw0KPiBzdGF0ZW1lbnRzIHRocm91Z2ggdGhlIERO UywgaXQgaXMgdXNlZnVsIHRvIGhhdmUgc29tZSBiYWNrZ3JvdW5kIGRhdGENCj4gdG8gaGVscCBl dmFsdWF0ZSB0aGVtLiBJbiBwYXJ0aWN1bGFyIHRvIGhhdmUgcmVmZXJlbmNlIHRvIHNvbWUgYWdl bnQNCj4gdGhhdCBrbm93cyB0aGUgaGlzdG9yeSBvZiB0aGF0IHNlY3VyaXR5IHBvbGljeSBhbmQg dGhlIG51bWJlciBvZg0KPiB2aW9sYXRpb25zIGJlaW5nIHJlcG9ydGVkIGFnYWluc3QgaXQuDQoN ClRoaXMgaXMgYW4gYXBwbGljYXRpb24tc3BlY2lmaWMgcG9saWN5LCBhcHBsaWVkIGJ5IHBlb3Bs ZSB3aG8gZG9uJ3Qgb3duIHRoZSByaWdodHMgdG8gdGhlIG1hdGVyaWFsIHRoZXkncmUgdHJhbnNw b3J0aW5nLiAgSXQgaXMgbmVjZXNzYXJpbHkgbGltaXRlZC4gIFRoZSBvbmUgd2hvIGRvZXMgY2Fu IGRvIGEgbXVjaCBiZXR0ZXIgYW5kIG1vcmUgdGhvcm91Z2ggam9iIG9mIGFwcGx5aW5nIGFuZCBl bmZvcmNpbmcgcG9saWN5Lg0KDQouLi5idXQgb25seSBpZiB0aGUgdG9vbHMgZXhpc3QuDQoNCj4g RGVwbG95aW5nIGNyeXB0byBpcyBhY3R1YWxseSBxdWl0ZSBoYXJkIGZvciB0aGUgdHlwaWNhbCBu ZXR3b3JrDQo+IGFkbWluaXN0cmF0b3Igd2hvIGlzIHJhdGhlciBtb3JlIGNvbXBldGVudCBpbiBX b3JsZCBvZiBXYXJjcmFmdCB0aGFuDQo+IFBLSSB0byBiZSBob25lc3QuIFdoYXQgYWxtb3N0IGV2 ZXJ5b25lIGluIElFVEYgbGFuZCB0ZW5kcyB0byBiZSB1bmFibGUNCj4gdG8gZ3Jhc3AgaXMgdGhh dCB0aGV5IGFyZSBtZW1iZXJzIG9mIHRoZSB0ZWNobm9sb2dpY2FsIDElIGFuZCB0aGF0DQo+IHdo YXQgdGhleSBmaW5kIG9idmlvdXMsIHRoZSA5OSUgd2lsbCBmaW5kIGFueXRoaW5nIGJ1dC4NCg0K WW91J3JlIHJpZ2h0LCBpdCBpcyBhIHByb2JsZW0uICBXZSBuZWVkIHRvIHNvbHZlIGl0Lg0KDQpT b21lb25lIG1lbnRpb25lZCAiaWYgdGhlIHByb2JsZW0gd2VyZSBhIGhlYWRlciwgd2Ugd291bGQg aGF2ZSBzb2x2ZWQgaXQgYnkgbm93Ii4gIEkgdGhpbmsgdGhlIHByb2JsZW0gaXMgdGhlIGJveCB0 aGF0IGV2ZXJ5b25lIHNlZW1zIHRvIGJlIHRoaW5raW5nIHdpdGhpbi4gIEluc3RlYWQgb2YgdGhp bmtpbmcgYWJvdXQgaXQgZnJvbSBvdXRzaWRlIHRoZSBpbnRlcmFjdGlvbiwgd2Ugc2hvdWxkIGJl IGNvbnNpZGVyaW5nIHdoYXQgd2Ugd2FudCB0byBzZWUgYW5kIHdoYXQgd2Ugd2FudCB0byBzaGFy ZSB3aGVuIHdlJ3JlIG9uZSBvZiB0aGUgZW5kcG9pbnRzLiAgV2Ugc2hvdWxkIGJlIGNvbnNpZGVy aW5nIHdoYXQgd2Ugd2FudCBmcm9tIG91ciBzeXN0ZW1zLCBub3QgbWVyZWx5IHRyeWluZyB0byBk aWN0YXRlIHdoYXQgd2UgdGhpbmsgb3RoZXIgcGVvcGxlIHNob3VsZCB3YW50IGZyb20gdGhlaXJz LiAgV2Ugc2hvdWxkIGNvbnNpZGVyIHdoYXQgb3VyIG93biBjdXN0b21lcnMgbmVlZCBmcm9tIHVz LCBub3QgbWVyZWx5IHdoYXQgd2UgdGhpbmsgdGhleSBuZWVkLg0KDQotS3lsZSBIDQoNCj4gU28g dGhlIHRoaW5nIHRoYXQgc2F2ZWQgREtJTSBwb2xpY3kgc3RhdGVtZW50cyB3YXMgdGhlIGZhY3Qg dGhhdCB0aGV5DQo+IGFyZSBvbmx5IGludGVycHJldGVkIGJ5IHNlcnZpY2VzIHRoYXQgYXJlIGFj dHVhbGx5IHZlcnkgZXhwZXJpZW5jZWQgaW4NCj4gaGFuZGxpbmcgYmFkIGRhdGEgYW5kIGluIGZh Y3QgZGF0YSB0aGF0IHBlb3BsZSBhcmUgaW50ZW50aW9uYWxseQ0KPiB0cnlpbmcgdG8gY29ycnVw dC4NCj4NCj4gT24gV2VkLCBGZWIgOCwgMjAxMiBhdCAxMDowOSBQTSwgS3lsZSBIYW1pbHRvbiA8 YWVyb3dvbGZAZ21haWwuY29tPiB3cm90ZToNCj4+IE9uY2UgdXBvbiBhIHRpbWUgaW4gdGhlIElF VEYsIHRoZXJlIHdhcyBhIG1hbmRhdG9yeS10by1pbXBsZW1lbnQgY2lwaGVyLg0KPj4goFRoaXMg Y2lwaGVyIHdhcyB0aGUgYmVzdC1zZWxlY3RlZCBhdCB0aGUgdGltZSwgdXNpbmcgY3V0dGluZy1l ZGdlDQo+PiB0ZWNobm9sb2dpZXMuDQo+Pg0KPj4gVGltZSBjaGFuZ2VkLiCgVGhlIG5ldyBtYW5k YXRvcnktdG8taW1wbGVtZW50IGNpcGhlciBjYW1lIGFsb25nLg0KPj4NCj4+IFdoeSBoYXZlbid0 IHdlIGV2ZXIgY29uc2lkZXJlZCB0aGF0IG1heWJlIFMvTUlNRSBkb2Vzbid0IGhhdmUgdG8gYmUg ZnVsbHkNCj4+IGF1dGhlbnRpY2F0ZWQgb24gZmlyc3QgY29udGFjdD8goFdoeSBoYXZlbid0IHdl IGNvbnNpZGVyZWQgdGhhdCB3aXRoIG9ubHkgYQ0KPj4gc2luZ2xlIGNlcnRpZmljYXRlIGNoYWlu LCB0aGUgdXNlciB3b3VsZCBmaXJzdCBoYXZlIHRvIGNvbW11bmljYXRlIGhpcyBNVUENCj4+IGNh cGFiaWxpdGllcyB0byBoaXMgQ0EgYW5kIHRoZW4gbm90IHVwZ3JhZGUgaGlzIG1haWwgY2xpZW50 IHdpdGhvdXQNCj4+IGNvb3JkaW5hdGlvbj8NCj4+DQo+PiBJbnN0ZWFkLCB3ZSBzaG91bGQgaGF2 ZSBhIG5ldyBoZWFkZXIgaW4gb3VyIGVtYWlsLg0KPj4goFgtU2VjdXJlLU1JTUUtQ2FwYWJpbGl0 aWVzOg0KPj4NCj4+IFdlIGNvdWxkIG1ha2UgaXQgY29udGFpbiBhIGJhc2U2NC1lbmNvZGVkIHJl cHJlc2VudGF0aW9uIG9mIHdoYXQgdGhlDQo+PiBDYXBhYmlsaXRpZXMgZXh0ZW5zaW9uJ3MgT0NU RVQgU1RSSU5HIHdvdWxkIGNvbnRhaW4uIKBPciB3ZSBjb3VsZCBhc3NpZ24NCj4+IGxhYmVscyB0 byB0aGUgdmFyaW91cyBjaXBoZXIgYWxnb3JpdGhtcyB0byBtYWtlIHRoZW0gaHVtYW4tcmVhZGFi bGUuDQo+Pg0KPj4gSW5zdGVhZCBvZiB0aGlua2luZyBhbG9uZyB0aGUgbGluZXMgb2YgIm9ubHkg dGhlIG5hbWVkIHJlY2lwaWVudCB3aWxsIGdldA0KPj4gaXQiLCB3aHkgZG9uJ3Qgd2Ugc3RhcnQg dGhpbmtpbmcgYWxvbmcgdGhlIGxpbmVzIG9mICJ0aGUgZGVzdGluYXRpb24gbWFpbGJveA0KPj4g d2lsbCBiZSBhYmxlIHRvIGdldCBpdCI/DQo+Pg0KPj4gRnJvbSB0aGVyZSwgaXQgYmVjb21lcyBm YWlybHkgZWFzeS4goCJJIG11c3QgZW5zdXJlIHRoYXQgdGhlIHN5bW1ldHJpYyBrZXkNCj4+IHVz ZWQgdG8gZW5jcnlwdCB0aGUgbWVzc2FnZSBjYW4gYmUgZGVjcnlwdGVkIGJ5IGFsbCBvZiBteSB1 c2VyIGRldmljZXMgYW5kDQo+PiByZWNvdmVyeSBrZXlzLiIgoEEgcHJvY21haWwgcmVjaXBlIGNv dWxkIHBlcmhhcHMgcmUtc2VuZCB0aGUgbWVzc2FnZSB3aXRoDQo+PiBhZGRpdGlvbmFsIHJlY2lw aWVudCBrZXlzLg0KPj4NCj4+IEF0IHRoYXQgcG9pbnQsIGl0J3MgIndoYXQgaWYgSSBkb24ndCBo YXZlIG15IGtleXMgb24gdGhlIGRldmljZSB3aGVyZSBJIGNhbg0KPj4gcnVuIHByb2NtYWlsPyIg oElNQVAgYmVjb21lcyBhIHVzZWZ1bCB0b29sLCBhcyBkb2VzIFBPUDMuIKBUaGV5IGNhbid0IGFs dGVyDQo+PiBtZXNzYWdlcywgYnV0IHRoZXkgcGVybWl0IGEgZGFlbW9uIHRoYXQgY2FuLCBmb3Ig ZXhhbXBsZSwgZW5zdXJlIHRoYXQgaXRzDQo+PiByZShtdWx0aXBseSlkZXN0aW5lZCBtZXNzYWdl cyBtYWtlIGl0IGJhY2sgaW50byB0aGUgbWFpbGJveCBiZWZvcmUgdGhlDQo+PiBvcmlnaW5hbCwg c2luZ2xlLWRlc3RpbmF0aW9uIG1lc3NhZ2UgaXMgcHVyZ2VkLg0KPj4NCj4+IFRoaXMgd291bGQg YWxzbyBhbGxvdyBmb3IgYWRkaXRpb25hbCBjb21tYW5kcyB0byBiZSBzZW50IGZyb20gdGhlIGRl dmljZXMgdG8NCj4+IHRoZSBrZXlzdG9yZSwgc3VjaCBhcyAic2lnbiB0aGlzIHdpdGggbXkgY29y cG9yYXRlIGtleSIgb3IgInNlbmQgdGhpcyB0bw0KPj4gYWVyb3dvbGZAZ21haWwuY29tIHdpdGgg dGhlIGJlc3Qgc2VjdXJpdHkgeW91IGtub3cgaG93IHRvIGRvIi4NCj4+DQo+PiBUaGUgcHJvYmxl bSBpcy4uLj8NCj4+DQo+PiAtS3lsZSBIDQo+Pg0KPj4gT24gV2VkLCBGZWIgOCwgMjAxMiBhdCA2 OjExIFBNLCBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+DQo+PiB3 cm90ZToNCj4+Pg0KPj4+DQo+Pj4gPHRyeWluZyB0byBwb2tlIHRoaW5ncyBhbG9uZyBhIGJpdCBt b3JlIGFjdGl2ZWx5IGhhdCBvbj4NCj4+Pg0KPj4+IFNvIFMvTUlNRSB3b3JrcyBmaW5lIGluIG1h bnkgY2FzZXMgYnV0IGRvZXMgbm90IHdvcmsgd2VsbA0KPj4+IGJldHdlZW4gcmFuZG9tIHBlb3Bs ZSBjb25uZWN0ZWQgdG8gdGhlIEludGVybmV0LCB1bmxpa2UgZW1haWwuDQo+Pj4gVGhhdCdzIGEg cGl0eS4NCj4+Pg0KPj4+IEl0cyBub3QgYW4gZWFzeSBwcm9ibGVtIHRob3VnaCwgWE1QUCBoYXZl IGJlZW4gdHJ5aW5nIGZvciBhDQo+Pj4gZ29vZCB3aGlsZSBhbmQgd2UgZG9uJ3QgZXZlbiBzZWVt IHRvIGhhdmUgYSBnb29kIHNvbHV0aW9uIGZvcg0KPj4+IFNJUCBvciBEaWFtZXRlciB3aGljaCBv dWdodCBiZSBtdWNoIGVhc2llci4NCj4+Pg0KPj4+IEkgZ3Vlc3MgaWYgdGhpcyBkaXNjdXNzaW9u IGxlYWQgdG8gYSB3YXkgdG8gbWFuYWdlIGtleXMgdGhhdA0KPj4+IGNvdWxkIHdvcmsgYXQgdGhl IHNhbWUgc2NhbGUgYXMgZW1haWwgdGhhdCB3b3VsZCBiZSBhIG1ham9yDQo+Pj4gYWR2YW5jZS4g SSBkb24ndCBleHBlY3QgdGhhdCBteXNlbGYuDQo+Pj4NCj4+PiBBbmQgb2YgY291cnNlLCB3aGF0 ZXZlciB0aGUgcmlnaHQgYW5zd2VyIHRoZXJlIChpZiB0aGVyZQ0KPj4+IGlzIG9uZSkgaXMgbWF5 YmUgdmVyeSBkaWZmZXJlbnQgZnJvbSBob3cgd2UgbWlnaHQgbWFuYWdlIGtleXMNCj4+PiBmb3Ig d2ViIHNlcnZlcnMgb3IgTVRBcyBvciBYTVBQIHNlcnZlcnMuDQo+Pj4NCj4+PiBNYXliZSB3ZSBv dWdodCBhbHNvIHRoaW5rIGFib3V0IHdoZXRoZXIgb3Igbm90IHRoZSBzYW1lIGtleQ0KPj4+IG1h bmFnZW1lbnQgc2NoZW1lIGlzIHJpZ2h0IGZvciBhbGwgdGhvc2Ugb3Igbm90IGFzIHBhcnQgb2YN Cj4+PiB0aGlzIHRvbyBhbmQgd2hldGhlciB3ZSdyZSBhYmxlIHRvIHNvbHZlIGFsbCBvciBqdXN0 IHNvbWUvb25lDQo+Pj4gb2YgdGhvc2UgcHJvYmxlbXMuDQo+Pj4NCj4+PiBQdXQgYW5vdGhlciB3 YXk6IG1heWJlIGl0J2QgYmUgYmV0dGVyIHRvIHRpZ2h0ZW4gdGhlIGZvY3VzDQo+Pj4gYSB0ZWVu eSBiaXQgbW9yZSBvbiB0aGlzIGxpc3QuIFNwZWNpZmljIHN1Z2dlc3Rpb25zIGZvciB0b3BpY3MN Cj4+PiB3ZWxjb21lLiBXaHkgbm90IHN0YXJ0IGEgbmV3IHRocmVhZCB3aXRoIHlvdXIgZmF2b3Vy aXRlDQo+Pj4gcHJvYmxlbSB0aGF0J3Mgd29ydGggc29sdmluZyBhbmQgbWF5YmUgc29sdmVhYmxl LiAoQmVpbmcgdGhlDQo+Pj4gSUVURiwgd2UncmUgbm90IHZlcnkgaW50ZXJlc3RlZCBpbiBvdGhl ciB0aGluZ3MgaW4gdGhlIGVuZDotKQ0KPj4+DQo+Pj4gUy4NCj4+Pg0KPj4+IFBTOiBJIGJldCBJ J20gbm90IHRoZSBvbmx5IG9uZSB3aG8gY2FuIG5vIGxvbmdlciBhc3NvY2lhdGUNCj4+PiB0aGUg c3ViamVjdCBsaW5lIHdpdGggdGhlIGNvbnRlbnQuIEJlIGdvb2QgdG8gYmUgYmV0dGVyIGF0DQo+ Pj4gdGhhdCBzaW5jZSBpdCdsbCBoZWxwIHRvIHRyeSBtb3ZlIHRvd2FyZHMgc29tZSBjb25jcmV0 ZQ0KPj4+IG91dGNvbWVzIGhlcmUuDQo+Pj4NCj4+PiBPbiAwMi8wOS8yMDEyIDAxOjIyIEFNLCBQ aGlsbGlwIEhhbGxhbS1CYWtlciB3cm90ZToNCj4+Pj4NCj4+Pj4NCj4+Pj4gQWxpY2UgaGFzIHRo cmVlIG1vYmlsZSBwaG9uZXMgYW5kIHNpeCBsYXB0b3BzLg0KPj4+Pg0KPj4+PiBVc2luZyBlbWJl ZGRlZCBrZXlzIGluIHRob3NlIGRldmljZXMgZm9yIGF1dGhvcml6YXRpb24gaXMgbm8gcHJvYmxl bQ0KPj4+PiBzaW5jZSBlYWNoIGRldmljZSBjYW4gaGF2ZSBhIHNlcGFyYXRlIHByaXZhdGUga2V5 IGFuZCB0aGUNCj4+Pj4gYXV0aGVudGljYXRpb24gc2VydmVyIHRyYWNrcyB0aGUgZmFjdCB0aGF0 IHRoZXJlIGFyZSBuaW5lIGRldmljZXMgdGhhdA0KPj4+PiBtaWdodCBhdXRoZW50aWNhdGUgQWxp Y2UuDQo+Pj4+DQo+Pj4+IFRoZSBzYW1lIG1vZGVsIGNhbiBldmVuIGJlIG1hZGUgdG8gd29yayBm b3IgY29uZmlkZW50aWFsaXR5LiBBbGljZSBjYW4NCj4+Pj4gcmVhZCBoZXIgRFJNIHByb3RlY3Rl ZCBLaW5kbGUgY29udGVudCBvbiBhbnkgb25lIG9mIHRob3NlIGRldmljZXMuDQo+Pj4+IChUaG91 Z2ggdGhlcmUgbWF5IGJlIGxpbWl0cyBvbiBob3cgbWFueSBkZXZpY2VzIHRoZSBEUk0gc2NoZW1l IHdpbGwNCj4+Pj4gcGVybWl0KS4NCj4+Pj4NCj4+Pj4NCj4+Pj4gVHJ5aW5nIHRvIG1ha2UgUy9N SU1FIGVtYWlsIHdvcmsgaW4gdGhhdCBzY2VuYXJpbyBpcyBmdXRpbGUuIFRoZQ0KPj4+PiBzZW5k ZXIgb25seSB0cmFja3Mgb25lIHByaXZhdGUga2V5IGZvciBBbGljZS4gU28gQWxpY2UgaGFzIHRv IGV4cG9ydA0KPj4+PiBoZXIgcHJpdmF0ZSBrZXkgdG8gYWxsIGhlciBTL01JTUUgY2xpZW50cy4g Tm90IG9ubHkgaXMgdGhhdCB0ZXJyaWJsZQ0KPj4+PiBzZWN1cml0eSBwcmFjdGljZSwgaXQgaXMg dG9vIG11Y2ggd29yay4gV29yc2UsIEFsaWNlIGhhcyB0byByZXBlYXQgdGhlDQo+Pj4+IHByb2Nl c3Mgb25jZSBhIHllYXIuDQo+Pj4+DQo+Pj4+IFRoYXQgaXMgd2h5IEkgbm8gbG9uZ2VyIGJlbGll dmUgdGhhdCBlbmQtdG8tZW5kIGlzIGEgZGVzaXJhYmxlDQo+Pj4+IHF1YWxpdHkuIEEgc2VjdXJp dHkgcmVxdWlyZW1lbnQgdGhhdCBkb2VzIG5vdCBjb25zaWRlciB0aGUgY29zdCBpdA0KPj4+PiBp bXBvc2VzIHZlcnN1cyB0aGUgcmlza3MgaXQgbWl0aWdhdGVzIGlzIGlkZW9sb2d5Lg0KPj4+Pg0K Pj4+Pg0KPj4+PiBPbiBXZWQsIEZlYiA4LCAyMDEyIGF0IDQ6NTIgUE0sIFN0ZXBoZW4gS2VudDxr ZW50QGJibi5jb20+IKB3cm90ZToNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gQXQgMzowMyBQTSAtMDUw MCAyLzgvMTIsIFBoaWxsaXAgSGFsbGFtLUJha2VyIHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+ Pj4+Pg0KPj4+Pj4+IEJ1dCBhdXRoZW50aWNhdGlvbiB3b3JrcyBpbiB0aGF0IHNjZW5hcmlvIGJl Y2F1c2UgdGhlIHByb3RvY29scyBjYW4NCj4+Pj4+PiBhbGxvdw0KPj4+Pj4+IGVhY2ggdXNlciB0 byBoYXZlIGFzIG1hbnkga2V5cyBhcyB0aGV5IG5lZWQuIFRoZSBrZXkgaXMgbm90IHNoYXJlZA0K Pj4+Pj4+IGFjcm9zcw0KPj4+Pj4+IGRldmljZXMsIHRoZSBwcm90b2NvbHMgYWxsb3cgZm9yIG11 bHRpcGxlIGNhcmRzIHBlciBlbmQgdXNlcg0KPj4+Pj4+DQo+Pj4+PiBTb3JyeSwgSSBkb24ndCB1 bmRlcnN0YW5kIHlvdSBjb21tZW50Lg0KPj4+Pj4NCj4+Pj4+IFN0ZXZlDQo+Pj4+DQo+Pj4+DQo+ Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+PiB0aGVyaWdodGtleSBtYWlsaW5nIGxpc3QNCj4+PiB0aGVyaWdodGtl eUBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGhl cmlnaHRrZXkNCj4+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiB0aGVyaWdodGtleSBtYWlsaW5nIGxpc3QNCj4+IHRoZXJpZ2h0 a2V5QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ro ZXJpZ2h0a2V5DQo+Pg0KPg0KPg0KPg0KPiAtLQ0KPiBXZWJzaXRlOiBodHRwOi8vaGFsbGFtYmFr ZXIuY29tLw0KDQo= --gmsm1.9.5eqgyp2ydh5cccffr1vkh2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTYwMDU3MjJaMCMGCSqGSIb3DQEJBDEWBBTEM1K7PVlGyb+kWFFaBUZA C9wFHjBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAR5vHjtmmXrjRObS1W4MPT9XBbG8iCb8EtiZSsPuz+2dYW7WEVDi++HhLjLSTxBb1dD2h JKbkHlWKr2R61io0AarGLoap+anpg2tBq9b+sZIIGfIUL/OMVx4IdOxuG2If8HUb37KRqu+SE7h/ RZt3APwtLZUjfFCD8zWL3Zk8RMJVbYeN9gif1bmnG1rh0H55eZr3cf9ngNUsXzsUcs/ilc8uuh7a HddmM9tiALAZeOT5XX3CelHds23JBDKX1td2f0T1p2hDq8XWoAt0jeV5pCrNi1LhRnBYwPel2y3Z r7jbhUHn8RHv+7FgZlIa4ah8dHsg/X+11+Z/ZPOj86qH0QAAAAAAAA== --gmsm1.9.5eqgyp2ydh5cccffr1vkh2-- From aerowolf@gmail.com Wed Feb 15 19:56:57 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB54721E8014 for ; Wed, 15 Feb 2012 19:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVQhrfinu6m8 for ; Wed, 15 Feb 2012 19:56:57 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7483721E800E for ; Wed, 15 Feb 2012 19:56:57 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2176713pbc.31 for ; Wed, 15 Feb 2012 19:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=cZLT8P2eMM2pIz5ei1iwXubRtsg1/PEJlHu/EIzoQKU=; b=kVJcUpFOoQ9lYEJ+T9D3dHWqaSLhTxLmnRqpBA2ZhwnqgrCcZfOvRb8haQ8SpCA4c4 CT20fXTy/6PVk95vZ5exj0tBlqWj17HeqhdgIYgttS3Lo8yqp7PvrHSHpvE+Rg9Yhm/r p0euB0rhE4VkVLAXNX5z23Kb3dQ3ovfdUXKik= Received: by 10.68.116.234 with SMTP id jz10mr9386929pbb.84.1329364617329; Wed, 15 Feb 2012 19:56:57 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id b4sm12756543pbc.7.2012.02.15.19.56.54 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 19:56:55 -0800 (PST) From: "Kyle Hamilton" To: "Phillip Hallam-Baker" Date: Wed, 15 Feb 2012 19:56:55 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgyp9d9sdk3aoegn9wk2 Cc: Nico Williams , "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 03:56:58 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgyp9d9sdk3aoegn9wk2 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit On Thu, Feb 9, 2012 at 5:16 AM, Phillip Hallam-Baker wrote: > So now we see why security policy driven by MUA published security > policy is going to fail: there is no consistency in the MUA loop. I > read mail on four separate devices. They have no way to communicate > between themselves to negotiate a common security policy and I > certainly would not want them to. 'Certainly'? You wouldn't want your systems to work together to seamlessly and transparently add protections to all of your personal intellectual property, permitting secure access from devices which you enrolled or otherwise authorized, with potentially a completely transparent and automatic secure authorization process? You wouldn't want your systems to automatically and securely manage your utility and ceremonial keys so that your command is the only one which can permit their application? You wouldn't want your systems to implement key expiration and rollover, or automatically enroll new keys into new PKIs as such would become useful? I'm sorry, but I would. And I do. The Person is the one who specifies policy. Not the service that the Person hires to carry his mail or his traffic. (The service may indeed specify its own policies, but that's the Terms of Service, part of the contract between two Persons (individual and corporate), and only of note if the service must cut the individual off for their violation.) -Kyle H --gmsm1.9.5eqgyp9d9sdk3aoegn9wk2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTYwMzU2NTVaMCMGCSqGSIb3DQEJBDEWBBRyZxKTXMHeUNmflqVsj5Kz uK5x5DBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAEiMvcGA7/77u9mA1Je1oO+ZRCd2nbbZsbAfr6Zh7PkHSC9osSvxIIcb/grHLPRBvPXWL Pbz15qrWvT92Z3t+GOWaGFRXMPmicnhdX1+8sx+BK9r8iPpMQQNFd2qkZbmyovy5W+AA7ENfh369 9OeZf5wW5XllDZm+7dLrLib00IVFR5rNF0Al2J/XYwpFNj4O7EKOKl59Ra0TIFTP5lcHnPZBz9Yn pJkaJ7I4m1rJce7QY4gcil9Eg0WWZX6fs4nwyZ70ZqSp1sU6kw8SAPBGrpHX/8sKl9Q015AVeMMj 0M3QSLjnrBr0SR+yixDuH2EM26UwmqUbqRLmjxeIDQIlGwAAAAAAAA== --gmsm1.9.5eqgyp9d9sdk3aoegn9wk2-- From mrex@sap.com Wed Feb 15 20:30:32 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5D721E8033 for ; Wed, 15 Feb 2012 20:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.131 X-Spam-Level: X-Spam-Status: No, score=-10.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpaHCIPHiD2J for ; Wed, 15 Feb 2012 20:30:32 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DDE5821E801A for ; Wed, 15 Feb 2012 20:30:31 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1G4ULAk007888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Feb 2012 05:30:21 +0100 (MET) From: Martin Rex Message-Id: <201202160430.q1G4UKY1000348@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Thu, 16 Feb 2012 05:30:20 +0100 (MET) In-Reply-To: from "Kyle Hamilton" at Feb 15, 12 07:56:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: nico@cryptonector.com, therightkey@ietf.org, hallam@gmail.com, stephen.farrell@cs.tcd.ie Subject: Re: [therightkey] Secure e-mail, X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 04:30:32 -0000 Kyle Hamilton wrote: > > Phillip Hallam-Baker wrote: > > > > So now we see why security policy driven by MUA published security > > policy is going to fail: there is no consistency in the MUA loop. I > > read mail on four separate devices. They have no way to communicate > > between themselves to negotiate a common security policy and I > > certainly would not want them to. > > 'Certainly'? You wouldn't want your systems to work together to > seamlessly and transparently add protections to all of your personal > intellectual property, permitting secure access from devices which you > enrolled or otherwise authorized, with potentially a completely > transparent and automatic secure authorization process? You wouldn't > want your systems to automatically and securely manage your utility > and ceremonial keys so that your command is the only one which can > permit their application? You wouldn't want your systems to implement > key expiration and rollover, or automatically enroll new keys into > new PKIs as such would become useful? > > I'm sorry, but I would. And I do. I certainly would NEVER want that. What you're calling for is a "single break-in" system, where breaking into one of your devices enables the attacker to immediately take posession of all your other devices for free. -Martin From mrex@sap.com Wed Feb 15 20:47:14 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73FD21E803B for ; Wed, 15 Feb 2012 20:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.133 X-Spam-Level: X-Spam-Status: No, score=-10.133 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QHut7rm0j4K for ; Wed, 15 Feb 2012 20:47:13 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 311CA21E8011 for ; Wed, 15 Feb 2012 20:47:13 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1G4l9Nx009638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Feb 2012 05:47:09 +0100 (MET) From: Martin Rex Message-Id: <201202160447.q1G4l8rN001273@fs4113.wdf.sap.corp> To: paul@marvell.com (Paul Lambert) Date: Thu, 16 Feb 2012 05:47:08 +0100 (MET) In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01579DA14D8@SC-VEXCH2.marvell.com> from "Paul Lambert" at Feb 14, 12 07:04:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: nico@cryptonector.com, therightkey@ietf.org, mrex@sap.com, aerowolf@gmail.com Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 04:47:14 -0000 Paul Lambert wrote: > > I notice you're still attaching a root certificate of unknown > quality as part of your signature. Since it is different than my > current class 2 root for the same named authority it may or may > not be valid. If I accept your certificate and root I'm potentially > at risk that you will later maliciously create MITM certs. Why do you care about the CA cert that signed Kyle's cert AT ALL? If you don't recognize that CA cert, they you should continue to completely ignore that CA cert. If your MUA does not let you pin Kyle's cert alone (for the purpose of verifying the signaturs on Kyles Emails), but requires you to add cert of _his_ certifcation chain to add to your trust anchors as a prerequisite for S/Mime signature verification, then the PKI software used by your MUA is seriously broken. -Martin From mrex@sap.com Wed Feb 15 21:24:33 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15C221E802A for ; Wed, 15 Feb 2012 21:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.134 X-Spam-Level: X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mssPCSd77X6f for ; Wed, 15 Feb 2012 21:24:32 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7FECF21E8011 for ; Wed, 15 Feb 2012 21:24:32 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1G5OOGd001393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Feb 2012 06:24:25 +0100 (MET) From: Martin Rex Message-Id: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Thu, 16 Feb 2012 06:24:23 +0100 (MET) In-Reply-To: from "Kyle Hamilton" at Feb 13, 12 05:44:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: nico@cryptonector.com, therightkey@ietf.org, mrex@sap.com, adam@cypherspace.org Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 05:24:34 -0000 Kyle, Kyle H wrote: > > We MUST permit every use of our protocols. We MUST describe the > computational processes and we MUST define the intended semantics, > but we MUST NOT try to sabotage anything that the standards' > implementors or consumers try to do. If we do, we're overstepping > the bounds of what authority we can legitimately claim as standards > designers. We seem to be talking about completely different protocols. *I* am talking about TLS (any version), which has the clearly stated design goal: http://tools.ietf.org/html/rfc2246 Abstract This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. http://tools.ietf.org/html/rfc5246 Abstract This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. What these MITM proxies are doing is _completely_and_thoroughly_ subverting the entire purpose of the TLS protocol. They're doing it not by exploiting weaknesses in the TLS protocol itself (at least prior to rfc5746), but instead, by exploiting a long-standing fatal design flaw in the security in the existing TLS X.509 PKI trust model. Those who want a protocol for encrypted communication that can be arbitrarily MITMed should design themselves such a protocol. Expecting the IETF to support continued exploitation of a serious weakness in a security architecture that is the exact opposite of its stated design goal is inappropriate for the IETF. -Martin From hallam@gmail.com Thu Feb 16 05:01:40 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A0D21F877C for ; Thu, 16 Feb 2012 05:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlJNe05s2JM7 for ; Thu, 16 Feb 2012 05:01:35 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD1E21F8735 for ; Thu, 16 Feb 2012 05:01:34 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3434507obb.31 for ; Thu, 16 Feb 2012 05:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PkjllBcKIMHAEaJrMBXdWXe2saGGXXNk5HpgRdq8Wwc=; b=D0E0/8UYS+13bnyfcIiNk6XdPrsMLKqrij2G6vRMBMwhbIdtxt208x5pxbAx+M7+Lj lX9pwMNBNoNmSF9sgDOJ4kSfPLbh9s6CJftmk80bVXK2ZKdy74rbi5lKVNFqOu7covpS zaPaBJOqEIydt573UoVdQ//M9KyQ2zhH2Y5Vs= MIME-Version: 1.0 Received: by 10.182.75.102 with SMTP id b6mr1902635obw.9.1329397294143; Thu, 16 Feb 2012 05:01:34 -0800 (PST) Received: by 10.182.75.138 with HTTP; Thu, 16 Feb 2012 05:01:33 -0800 (PST) In-Reply-To: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp> References: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp> Date: Thu, 16 Feb 2012 08:01:33 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: nico@cryptonector.com, therightkey@ietf.org, adam@cypherspace.org, Kyle Hamilton Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 13:01:40 -0000 The purpose of the IETF is to support USERS USERS ! Not designers. So the stated design goals have to be taken with a pinch of salt. They are almost always wrong. Presenting them as immutable statements of permanent truth is bogus. TLS and SSH are the only IETF security protocols thus far that have not turned out to be technical triumphs but deployment failures. It is really easy for someone to push for a technical perfection that makes the protocol undeployable or unusable. Here we are all agreed that it is generally a bad thing for there to be this particular hole. That is not the issue. The issue is whether ignoring the fact that there are regulatory requirements for this capability and not supporting them results in a better or a worse outcome for users. So far the evidence suggests that refusal to consider them has resulted in a worse outcome. On Thu, Feb 16, 2012 at 12:24 AM, Martin Rex wrote: > Kyle, > > Kyle H wrote: >> >> We MUST permit every use of our protocols. =A0We MUST describe the >> computational processes and we MUST define the intended semantics, >> but we MUST NOT try to sabotage anything that the standards' >> implementors or consumers try to do. =A0If we do, we're overstepping >> the bounds of what authority we can legitimately claim as standards >> designers. > > We seem to be talking about completely different protocols. > > *I* am talking about TLS (any version), which has the clearly stated > design goal: > > =A0http://tools.ietf.org/html/rfc2246 > > =A0 Abstract > > =A0 This document specifies Version 1.0 of the Transport Layer Security > =A0 (TLS) protocol. The TLS protocol provides communications privacy over > =A0 the Internet. The protocol allows client/server applications to > =A0 communicate in a way that is designed to prevent eavesdropping, > =A0 tampering, or message forgery. > > =A0http://tools.ietf.org/html/rfc5246 > > =A0 Abstract > > =A0 This document specifies Version 1.2 of the Transport Layer Security > =A0 (TLS) protocol. =A0The TLS protocol provides communications security > =A0 over the Internet. =A0The protocol allows client/server applications = to > =A0 communicate in a way that is designed to prevent eavesdropping, > =A0 tampering, or message forgery. > > > What these MITM proxies are doing is _completely_and_thoroughly_ > subverting the entire purpose of the TLS protocol. =A0They're doing > it not by exploiting weaknesses in the TLS protocol itself > (at least prior to rfc5746), but instead, by exploiting a long-standing > fatal design flaw in the security in the existing TLS X.509 PKI trust mod= el. > > Those who want a protocol for encrypted communication that can be > arbitrarily MITMed should design themselves such a protocol. > Expecting the IETF to support continued exploitation of a serious > weakness in a security architecture that is the exact opposite of > its stated design goal is inappropriate for the IETF. > > > -Martin > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --=20 Website: http://hallambaker.com/ From stephen.farrell@cs.tcd.ie Thu Feb 16 05:13:06 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84B521F8707 for ; Thu, 16 Feb 2012 05:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-O11SzbCqVW for ; Thu, 16 Feb 2012 05:13:01 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8903521F8715 for ; Thu, 16 Feb 2012 05:13:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7E17A171C97 for ; Thu, 16 Feb 2012 13:13:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1329397975; bh=oXeoLTbQZdnYtM J8HVbothgzNtKbrSGNdRMqEoUFfS4=; b=IsqH5XUIIEM6y/AI4r3dMZrfgXwPCu 7NZgDHxtyJxE37NTjMr2l6OOE0tZg+hqZYLj3kegFnxlLto9oxuZ2k7Zfz5RXjnb vAUURDYfgAe+p13tKkqp7ii4MbdRw+UeHK6VhErtp/Y4gPQbeYMI/L+AdEt+TkBU R0Oeqjtp4ZJucSJPqkpFDnR1OgS/ZFQehdYbbLcD+m560ThdcwLXpZfFMZ++VtjI ky6LF3VyNrqsQJMerM2m65Df3A3qEP5876h+F/breUiBjQQCIbHiiCIwWn2EuknT DO9QlsvRpr7HgEm5sZlN3/dI3/iwC2LHMaDqZWeQw+a1/wZURg/t8r7Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 8FWkvQ9bpdTn for ; Thu, 16 Feb 2012 13:12:55 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.29.237]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 775A7171C3B for ; Thu, 16 Feb 2012 13:12:55 +0000 (GMT) Message-ID: <4F3D00D7.8020305@cs.tcd.ie> Date: Thu, 16 Feb 2012 13:12:55 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <4F3C04C9.7040601@cs.tcd.ie> In-Reply-To: <4F3C04C9.7040601@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 13:13:07 -0000 Dunno if anyone else thinks this might be interesting but I do:-) So I sketched out an initial idea for how it might fit in here. [1] Comments welcome. S. [1] http://www.ietf.org/id/draft-farrell-kc-00.txt On 02/15/2012 07:17 PM, Stephen Farrell wrote: > > Hiya, > > I guess the recent publications about common factors [1,2] > are something else that this group might want to consider. > > I wonder if an rsa modulus checker protocol might help or > something. Not sure if that's something that could be run > quickly enough though, other than for the straight > duplicates or dumbass things with small factors you should > spot yourself. Anyone know? > > Or maybe you could register your public key and get a > nonce, then come back periodically to see if any problems > have been detected for your key. > > And yes, better prngs are needed, but there'll probably > always be bad ones out there. > > S. > > [1] http://eprint.iacr.org/2012/064 > [2] > http://it.slashdot.org/story/12/02/15/1540212/factorable-keys-twice-as-many-but-half-as-bad > > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From hallam@gmail.com Thu Feb 16 05:52:02 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAD021F8721 for ; Thu, 16 Feb 2012 05:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.386 X-Spam-Level: X-Spam-Status: No, score=-3.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TP9Z69fJt7Y6 for ; Thu, 16 Feb 2012 05:51:57 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9288621F8720 for ; Thu, 16 Feb 2012 05:51:57 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3501639obb.31 for ; Thu, 16 Feb 2012 05:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xmrd40XgZZtUVaeWCJVObX6V2UZHY1AlTDtFxYmvgr8=; b=pu0PwiO7Osj/7gepBGoKjIelZ8xMaPOZaPRzh7DCY9u37c7qqrfpWsppUBlS85JEdD Vusl2tcpJ4Tii8bRilLt0cIfh0wAdRMW/UEIM36DHz4QsoFC6G6txew7BbEOvsliSfEB WwOMY1fiajfTkQZKSDCZbbS0n0Rw9VKhFzN5w= MIME-Version: 1.0 Received: by 10.60.1.137 with SMTP id 9mr945707oem.39.1329400317237; Thu, 16 Feb 2012 05:51:57 -0800 (PST) Received: by 10.182.75.138 with HTTP; Thu, 16 Feb 2012 05:51:57 -0800 (PST) In-Reply-To: <4F3D00D7.8020305@cs.tcd.ie> References: <4F3C04C9.7040601@cs.tcd.ie> <4F3D00D7.8020305@cs.tcd.ie> Date: Thu, 16 Feb 2012 08:51:57 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 13:52:02 -0000 My first thought was that this should be done by the CA. Then it turns out that these are all (apparently) embedded systems generated keys and only some of those are CA certified. So maybe there is a need for this protocol. As I have mentioned before though, public key is problematic in embedded systems. Most of the systems don't have the resources to do the job right and this will only get worse as time goes on because as a $1 processor gets more powerful a chip with a 6502 core gets cheaper and more are made. More 6502 type chips were made last year than in any previous year. So my view is that we have to get away from the idea that the endpoint has to do public key crypto. I have developed technology (rights reserved) that moves the public key stuff off the endpoint device without creating holes the maker or key repository can exploit. On Thu, Feb 16, 2012 at 8:12 AM, Stephen Farrell wrote: > > Dunno if anyone else thinks this might be interesting > but I do:-) > > So I sketched out an initial idea for how it might fit > in here. [1] > > Comments welcome. > > S. > > [1] http://www.ietf.org/id/draft-farrell-kc-00.txt > > > On 02/15/2012 07:17 PM, Stephen Farrell wrote: >> >> >> Hiya, >> >> I guess the recent publications about common factors [1,2] >> are something else that this group might want to consider. >> >> I wonder if an rsa modulus checker protocol might help or >> something. Not sure if that's something that could be run >> quickly enough though, other than for the straight >> duplicates or dumbass things with small factors you should >> spot yourself. Anyone know? >> >> Or maybe you could register your public key and get a >> nonce, then come back periodically to see if any problems >> have been detected for your key. >> >> And yes, better prngs are needed, but there'll probably >> always be bad ones out there. >> >> S. >> >> [1] http://eprint.iacr.org/2012/064 >> [2] >> >> http://it.slashdot.org/story/12/02/15/1540212/factorable-keys-twice-as-many-but-half-as-bad >> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey -- Website: http://hallambaker.com/ From hallam@gmail.com Thu Feb 16 06:13:04 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAEB21F85FD for ; Thu, 16 Feb 2012 06:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.389 X-Spam-Level: X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVIylPLGT4a4 for ; Thu, 16 Feb 2012 06:13:00 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 71E5521F8636 for ; Thu, 16 Feb 2012 06:13:00 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3529429obb.31 for ; Thu, 16 Feb 2012 06:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KjCQxuizRL+83fkMB16HldCAWiZlh+jd7S8sjgJat/Q=; b=gOBpapXZm4etToEWyR+ZSPIT2sHUzTmdxsKcZ+JtPIOd9ZD5lB0aC3uJb+HCFGF0Ud F+S8ZzbqUPdRsyoaLbZDO6sMOCuYt2v7AFLaZHF4Wmcu69urP7DNT16hM9f1v8V98/G/ 5XGfasf9MhIlMjPAWV44XOcTgaS5wf6TwlLBA= MIME-Version: 1.0 Received: by 10.182.1.104 with SMTP id 8mr2040572obl.19.1329401580131; Thu, 16 Feb 2012 06:13:00 -0800 (PST) Received: by 10.182.75.138 with HTTP; Thu, 16 Feb 2012 06:13:00 -0800 (PST) In-Reply-To: <201202160430.q1G4UKY1000348@fs4113.wdf.sap.corp> References: <201202160430.q1G4UKY1000348@fs4113.wdf.sap.corp> Date: Thu, 16 Feb 2012 09:13:00 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: nico@cryptonector.com, therightkey@ietf.org, Kyle Hamilton , stephen.farrell@cs.tcd.ie Subject: Re: [therightkey] Secure e-mail, X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:13:05 -0000 A single break system that was deployed is 100% better than a system that will never be deployed. We have tried doing the undeployable approach to secure email for thirty years and it has not worked yet and shows no sign of becoming more deployable in the future. If we go back to the earliest security work at the O/S level by the likes of Tony Hoare and Butler Lampson we get to the idea that all security sensitive actions should be funneled through a single gating point that is pervasive. That works really well in the O/S world because in practice you can't stop a policy enforcement point from being a potential point of failure. The reason I dislike the peering model is that instead of one single point of failure you end up with fifty single points of failure. If Alice has her private key on every device that can read email then the loss of any one of those devices exposes her key and all the emails. On Wed, Feb 15, 2012 at 11:30 PM, Martin Rex wrote: > Kyle Hamilton wrote: >> >> Phillip Hallam-Baker wrote: >> > >> > So now we see why security policy driven by MUA published security >> > policy is going to fail: there is no consistency in the MUA loop. I >> > read mail on four separate devices. They have no way to communicate >> > between themselves to negotiate a common security policy and I >> > certainly would not want them to. >> >> 'Certainly'? =A0You wouldn't want your systems to work together to >> seamlessly and transparently add protections to all of your personal >> intellectual property, permitting secure access from devices which you >> enrolled or otherwise authorized, with potentially a completely >> transparent and automatic secure authorization process? =A0You wouldn't >> want your systems to automatically and securely manage your utility >> and ceremonial keys so that your command is the only one which can >> permit their application? =A0You wouldn't want your systems to implement >> key expiration and rollover, or automatically enroll new keys into >> new PKIs as such would become useful? >> >> I'm sorry, but I would. =A0And I do. > > I certainly would NEVER want that. > > What you're calling for is a "single break-in" system, where breaking > into one of your devices enables the attacker to immediately take > posession of all your other devices for free. > > -Martin --=20 Website: http://hallambaker.com/ From stephen.farrell@cs.tcd.ie Thu Feb 16 06:13:44 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C00E21F858A for ; Thu, 16 Feb 2012 06:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbALqjWsz2B9 for ; Thu, 16 Feb 2012 06:13:39 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A26221F86F2 for ; Thu, 16 Feb 2012 06:13:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 46B28171CE5; Thu, 16 Feb 2012 14:13:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1329401613; bh=u4mZ91rFS3k84+ YLZFVZMrVse3kxFkBmSmaq/t9F6xs=; b=frZkAglrpAYSJKYX5clywfAnzXjHHH Ek3MFo9YR8T1m24C7BMr1Du4v+3mS80sTWX0/Mcy8UvhjbA4a/+y174rukGbzLC0 3SjzXENCI/VjDkCdWb7+Yd/1Na+ImHlGEQUhcIcBxMrehLHH6GczQ59hRF5RejAp KFTneSPDaBFACMNk37XngO3Zon04KZlhgCTzwJqMjc56151r8Vr+iKJEV5vbPkf+ dRiitdS6cIkpoZb58I4xvOhlj2ZDbruaolRbiPrpr7wK3wjjZfCh8F2vwrCK/gcA dMqb3P4bWfnDISc7KhElnyDYhNQVxalHqlxydgU8MSOjeYSQHTQlMvOA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id VUia1mPe6BC1; Thu, 16 Feb 2012 14:13:33 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.29.237]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2FD4A171C3B; Thu, 16 Feb 2012 14:13:33 +0000 (GMT) Message-ID: <4F3D0F0C.6010707@cs.tcd.ie> Date: Thu, 16 Feb 2012 14:13:32 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4F3C04C9.7040601@cs.tcd.ie> <4F3D00D7.8020305@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:13:44 -0000 On 02/16/2012 01:51 PM, Phillip Hallam-Baker wrote: > My first thought was that this should be done by the CA. In the cited material, they also cover PGP and SSH keys and not every CA will have a collection beyond its own end entities so I don't think this is a CA function since its not checking one public key, but one public key against a population of keys and is independent of X.509, PGP, SSH etc. > Then it turns > out that these are all (apparently) embedded systems generated keys > and only some of those are CA certified. So maybe there is a need for > this protocol. That too. > > As I have mentioned before though, public key is problematic in > embedded systems. Most of the systems don't have the resources to do > the job right and this will only get worse as time goes on because as > a $1 processor gets more powerful a chip with a 6502 core gets cheaper > and more are made. More 6502 type chips were made last year than in > any previous year. > > > So my view is that we have to get away from the idea that the endpoint > has to do public key crypto. Well, that's one position but not necessarily the only one with merit. S > I have developed technology (rights > reserved) that moves the public key stuff off the endpoint device > without creating holes the maker or key repository can exploit. > > > On Thu, Feb 16, 2012 at 8:12 AM, Stephen Farrell > wrote: >> >> Dunno if anyone else thinks this might be interesting >> but I do:-) >> >> So I sketched out an initial idea for how it might fit >> in here. [1] >> >> Comments welcome. >> >> S. >> >> [1] http://www.ietf.org/id/draft-farrell-kc-00.txt >> >> >> On 02/15/2012 07:17 PM, Stephen Farrell wrote: >>> >>> >>> Hiya, >>> >>> I guess the recent publications about common factors [1,2] >>> are something else that this group might want to consider. >>> >>> I wonder if an rsa modulus checker protocol might help or >>> something. Not sure if that's something that could be run >>> quickly enough though, other than for the straight >>> duplicates or dumbass things with small factors you should >>> spot yourself. Anyone know? >>> >>> Or maybe you could register your public key and get a >>> nonce, then come back periodically to see if any problems >>> have been detected for your key. >>> >>> And yes, better prngs are needed, but there'll probably >>> always be bad ones out there. >>> >>> S. >>> >>> [1] http://eprint.iacr.org/2012/064 >>> [2] >>> >>> http://it.slashdot.org/story/12/02/15/1540212/factorable-keys-twice-as-many-but-half-as-bad >>> >>> _______________________________________________ >>> therightkey mailing list >>> therightkey@ietf.org >>> https://www.ietf.org/mailman/listinfo/therightkey >>> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey > > > From hallam@gmail.com Thu Feb 16 06:20:36 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A462D21F87A1 for ; Thu, 16 Feb 2012 06:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeyl76gfdKE8 for ; Thu, 16 Feb 2012 06:20:32 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5DF21F8562 for ; Thu, 16 Feb 2012 06:20:32 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3540515obb.31 for ; Thu, 16 Feb 2012 06:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ew/dCNFXY7w+AFmwoiEFKCqtRke+VE89+e+djadjqQA=; b=sXfKTG6jbmbq1kucUsjBdAqCTTawF7SI6Iu3MbX8PO8Eh+DMu11HeMIvRnnRz7Ry2L E3OjhMUEmbXGPMwqvisbi29V9MXQlMsiALx7jwTLWrpKR8clyDBZ8ExdfZ8exsp6iFkF w9nSATggm1a5JsGjLmcj1Q1jhdGcb8+nIH2/w= MIME-Version: 1.0 Received: by 10.182.160.37 with SMTP id xh5mr2041624obb.29.1329402031911; Thu, 16 Feb 2012 06:20:31 -0800 (PST) Received: by 10.182.75.138 with HTTP; Thu, 16 Feb 2012 06:20:31 -0800 (PST) In-Reply-To: <4F3D0F0C.6010707@cs.tcd.ie> References: <4F3C04C9.7040601@cs.tcd.ie> <4F3D00D7.8020305@cs.tcd.ie> <4F3D0F0C.6010707@cs.tcd.ie> Date: Thu, 16 Feb 2012 09:20:31 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:20:36 -0000 On Thu, Feb 16, 2012 at 9:13 AM, Stephen Farrell wrote: > > > On 02/16/2012 01:51 PM, Phillip Hallam-Baker wrote: >> >> My first thought was that this should be done by the CA. > > > In the cited material, they also cover PGP and SSH keys and > not every CA will have a collection beyond its own end > entities so I don't think this is a CA function since its > not checking one public key, but one public key against > a population of keys and is independent of X.509, PGP, SSH > etc. > > >> Then it turns >> >> out that these are all (apparently) embedded systems generated keys >> and only some of those are CA certified. So maybe there is a need for >> this protocol. > > > That too. Problem being that it is probably easier to implement a RNG right than to implement any additional protocol for checking. Or at least the only people who are likely to implement your protocol are people who (1) would do the RNG right or (2) are required to for an audit requirement. It would be really nice if there was some way to audit RNGs algorithmically... >> As I have mentioned before though, public key is problematic in >> embedded systems. Most of the systems don't have the resources to do >> the job right and this will only get worse as time goes on because as >> a $1 processor gets more powerful a chip with a 6502 core gets cheaper >> and more are made. More 6502 type chips were made last year than in >> any previous year. >> >> >> So my view is that we have to get away from the idea that the endpoint >> has to do public key crypto. > > > Well, that's one position but not necessarily the only one > with merit. Well certainly it is better that they do have a PKI stack but only if they do it right and that puts us way above what a PIC controller class chip with only a few Kb can be expected to do. Hence we need to have two tracks. Rather than telling people that they must do PKI on 16 bit chips, maybe have a different approach there. -- Website: http://hallambaker.com/ From stephen.farrell@cs.tcd.ie Thu Feb 16 06:29:30 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6646B21F87A2 for ; Thu, 16 Feb 2012 06:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWkFRsWCA4tF for ; Thu, 16 Feb 2012 06:29:26 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B5F6021F8700 for ; Thu, 16 Feb 2012 06:29:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 2BBC4171C97; Thu, 16 Feb 2012 14:29:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1329402564; bh=AQUTDQUBZhZEuA d5V9/1HT6jI201PH4tsJxjlvWJlHE=; b=GEzK8Rpaw+JKTMJEw5h5f8XSwhwVtB PxVUy/Sw0spNG5W1ZNSBRE2VSth1+dnnujFcctZnpIuUunBMyv7JDVqw+FNRADYU CDNmUGO+17dhup2yZ6qEsD+QNK8/+2dQ4zEZUC6GEbew424oR1sX81ppc70CQZra Trw81GaR6ukkyrOwt4OL/wuJd8bzXsTiwT/fzDNCUBjotfhEE62z3RRMZcqO7qcc cYwE3aEQsEclIAZZr0DHn6BV9EHv2nd6jMr1AsmxquF4602tr4abxN2U5sbca3AA uFD4kCekcxzZgWLElfbHlw31RfkLB/TliyUtLfB/Xg6GRgAniFpf7qlQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Orh3jpiFEkJO; Thu, 16 Feb 2012 14:29:24 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.29.237]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B5F8B171C3B; Thu, 16 Feb 2012 14:29:24 +0000 (GMT) Message-ID: <4F3D12C4.3060901@cs.tcd.ie> Date: Thu, 16 Feb 2012 14:29:24 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4F3C04C9.7040601@cs.tcd.ie> <4F3D00D7.8020305@cs.tcd.ie> <4F3D0F0C.6010707@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 14:29:30 -0000 On 02/16/2012 02:20 PM, Phillip Hallam-Baker wrote: > On Thu, Feb 16, 2012 at 9:13 AM, Stephen Farrell > wrote: >> >> >> On 02/16/2012 01:51 PM, Phillip Hallam-Baker wrote: >>> >>> My first thought was that this should be done by the CA. >> >> >> In the cited material, they also cover PGP and SSH keys and >> not every CA will have a collection beyond its own end >> entities so I don't think this is a CA function since its >> not checking one public key, but one public key against >> a population of keys and is independent of X.509, PGP, SSH >> etc. >> >> >>> Then it turns >>> >>> out that these are all (apparently) embedded systems generated keys >>> and only some of those are CA certified. So maybe there is a need for >>> this protocol. >> >> >> That too. > > Problem being that it is probably easier to implement a RNG right than > to implement any additional protocol for checking. Or at least the > only people who are likely to implement your protocol are people who > (1) would do the RNG right or (2) are required to for an audit > requirement. A fair point. But one we don't seem to be able to get right and there are to also be fair some subtleties. Apparently some of the problem is also not the PRNG algorithm, but rather when you call it. For example, the 1st prime generation might happen just after 1st boot when there're few sources of randomness on the device. So while the 2nd prime may be much more random the probability of the 1st one being the same as someone else's is high enough to be a problem. (Apparently. He repeated:-) So there might be reasons to call this even if you're confident of your key generation code, in case someone fed the PRNG a crap seed. S > > It would be really nice if there was some way to audit RNGs algorithmically... > > >>> As I have mentioned before though, public key is problematic in >>> embedded systems. Most of the systems don't have the resources to do >>> the job right and this will only get worse as time goes on because as >>> a $1 processor gets more powerful a chip with a 6502 core gets cheaper >>> and more are made. More 6502 type chips were made last year than in >>> any previous year. >>> >>> >>> So my view is that we have to get away from the idea that the endpoint >>> has to do public key crypto. >> >> >> Well, that's one position but not necessarily the only one >> with merit. > > Well certainly it is better that they do have a PKI stack but only if > they do it right and that puts us way above what a PIC controller > class chip with only a few Kb can be expected to do. > > Hence we need to have two tracks. Rather than telling people that they > must do PKI on 16 bit chips, maybe have a different approach there. > From tom@ritter.vg Thu Feb 16 07:07:03 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C36F21F87CD for ; Thu, 16 Feb 2012 07:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.794 X-Spam-Level: X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9U94A16z8QH for ; Thu, 16 Feb 2012 07:06:59 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2521F87C7 for ; Thu, 16 Feb 2012 07:06:58 -0800 (PST) Received: by lahl5 with SMTP id l5so2928461lah.31 for ; Thu, 16 Feb 2012 07:06:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=1mL9lwP9w53KHeVvihKrskVLGGMQKIPQs0jDxjwnnDg=; b=qcIQxWFyMGKBBDUl4D4/VCRP+VMjnr7Cg/cxXnvZgrLnO2dp/M8fidit+RuNtFFXPZ FXBPpcsvcGV6HmfBgxU98YwNB8P04zwlUwL9IiuA4Zjhu8TMEECvStTffLth3nwFzKe5 qsVf7H+Coz+zk7/+CCzEav+nATWkJ5Xq6Cx8Q= Received: by 10.152.147.38 with SMTP id th6mr1988047lab.47.1329404817104; Thu, 16 Feb 2012 07:06:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.38.4 with HTTP; Thu, 16 Feb 2012 07:06:37 -0800 (PST) In-Reply-To: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp> References: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp> From: Tom Ritter Date: Thu, 16 Feb 2012 10:06:37 -0500 Message-ID: To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnQ0oih1qLZbEAU0ERT23GzY3eHc0qB1rzHunQpSPa0Dm9r03vBYIoFQhBDbtjtK0EhQPi8 Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:07:03 -0000 On 16 February 2012 00:24, Martin Rex wrote: > What these MITM proxies are doing is _completely_and_thoroughly_ > subverting the entire purpose of the TLS protocol. =A0They're doing > it not by exploiting weaknesses in the TLS protocol itself > (at least prior to rfc5746), but instead, by exploiting a long-standing > fatal design flaw in the security in the existing TLS X.509 PKI trust mod= el. > > Those who want a protocol for encrypted communication that can be > arbitrarily MITMed should design themselves such a protocol. > Expecting the IETF to support continued exploitation of a serious > weakness in a security architecture that is the exact opposite of > its stated design goal is inappropriate for the IETF. I think it's important to remember that whatever the TLS, DANE, and any other working groups come up with - there will be an army of people waiting to break the very first implementation, and they will do so. I will be one of them. No matter what Firefox and this working group come up with, I will break it locally, so I have a non-nagging TLS MITM. Even if I have to go in and modify the browser source code itself. Why? Because I test web apps! I need a MITM tool like Burp, Fiddler[0], or Mallory[1] to let me modify the traffic after it leaves the browser, before it leaves the machine, so I can test the inputs (form fields, headers, methods, and whatever else) the server accepts. That simple, that benign, that necessary, and yet entirely able to be re-purposed for evil. On 16 February 2012 08:01, Phillip Hallam-Baker wrote: > Here we are all agreed that it is generally a bad thing for there to > be this particular hole. That is not the issue. The issue is whether > ignoring the fact that there are regulatory requirements for this > capability and not supporting them results in a better or a worse > outcome for users. > > So far the evidence suggests that refusal to consider them has > resulted in a worse outcome. I agree, but I don't really understand why everyone's arguing. It all seems to be tangent to the purpose of all the working groups I've seen, because ultimately, it's left at the discretion of the implementations. A:"We shouldn't enable MITM under any circumstances!" B:"Okay, do you want to outlaw local trust databases?" A:"No, that's implementation details." B:"Yea but.... that's how MITM works." or A:"We shouldn't talk about MITM in the protocol!" B:"Okay, but people are going to do it. Maybe we should have guidelines so users are notified?" A:"No!" C:"Isn't that up to the browser?" B:"Oh, yea." The only argument I could see worth debating is somehow _enabling_ MITM in the TLS protocol *itself*. And not only do I think that's a huuuge change, super-dangerous, I also think it's entirely unnecessary, because we already have a viable, working MITM solution: local trust stores. It seems to be a simple question: Will whatever "CA Solution/Improvement" we come up be expected to override local, user-set (or corporate IT-set) policy? If no, MITM will work - don't worry about it. If so, how do you expect to accomplish that, when I control everything on my machine?[2] -tom [0] Burp and Fiddler are proxies designed for fiddling with HTTP requests and responses [1] Mallory is designed to muck about with raw TCP packets [2] It *is* worth noting that the local policy engine/mechanism then becomes ripe for attack, and instead of compromising CAs, we'll see attacks that exploit bugs in it. But, we can deal with that. From hallam@gmail.com Thu Feb 16 08:18:16 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5E021F86B3 for ; Thu, 16 Feb 2012 08:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKj8r4TC7gqw for ; Thu, 16 Feb 2012 08:18:11 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBD221F8489 for ; Thu, 16 Feb 2012 08:18:11 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3688165obb.31 for ; Thu, 16 Feb 2012 08:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3vtcpjT2dxFphfo67Qw/L+uNPNV1CiMn6gvuWy9q0FU=; b=eV3pVrtVnsu2xRhA6CCc2WIRPevUytDgKGCyMCgbuk2sWNktADGujKPE04I0gVd5kW EUmn8npr+l8cEt0GtMcjK6WDYNmORiHusJKtaULd6yKRjqwzbFrxXLYGZFHLIcu5yYd1 n+D/E2pLaE54csS6CPp//AQ0B5TyvK7fBxSWM= MIME-Version: 1.0 Received: by 10.182.75.102 with SMTP id b6mr2392935obw.9.1329409089473; Thu, 16 Feb 2012 08:18:09 -0800 (PST) Received: by 10.182.75.138 with HTTP; Thu, 16 Feb 2012 08:18:09 -0800 (PST) In-Reply-To: References: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp> Date: Thu, 16 Feb 2012 11:18:09 -0500 Message-ID: From: Phillip Hallam-Baker To: Tom Ritter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: therightkey@ietf.org Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:18:16 -0000 All that I have seen proposed in this regard is to have a draft that states= : 1) This is a really bad idea in general 2) If you really have to do it then do it this way 2a) It is turned off by default 2b) It only permits the authorized MITM to intercept 2c) The user is repeatedly warned that MITM is taking place 2d) There is no way that any credentials or infrastructure created for authorized intercept can be used to support unauthorized intercept I would rather have a defined path for this than to see another iteration where the primary goal is to minimize the effort required for the IT staff deploying the system. On Thu, Feb 16, 2012 at 10:06 AM, Tom Ritter wrote: > On 16 February 2012 00:24, Martin Rex wrote: >> What these MITM proxies are doing is _completely_and_thoroughly_ >> subverting the entire purpose of the TLS protocol. =A0They're doing >> it not by exploiting weaknesses in the TLS protocol itself >> (at least prior to rfc5746), but instead, by exploiting a long-standing >> fatal design flaw in the security in the existing TLS X.509 PKI trust mo= del. >> >> Those who want a protocol for encrypted communication that can be >> arbitrarily MITMed should design themselves such a protocol. >> Expecting the IETF to support continued exploitation of a serious >> weakness in a security architecture that is the exact opposite of >> its stated design goal is inappropriate for the IETF. > > I think it's important to remember that whatever the TLS, DANE, and > any other working groups come up with - there will be an army of > people waiting to break the very first implementation, and they will > do so. =A0I will be one of them. > > No matter what Firefox and this working group come up with, I will > break it locally, so I have a non-nagging TLS MITM. =A0Even if I have to > go in and modify the browser source code itself. > > Why? Because I test web apps! =A0I need a MITM tool like Burp, > Fiddler[0], or Mallory[1] to let me modify the traffic after it leaves > the browser, before it leaves the machine, so I can test the inputs > (form fields, headers, methods, and whatever else) the server accepts. > =A0That simple, that benign, that necessary, and yet entirely able to be > re-purposed for evil. > > On 16 February 2012 08:01, Phillip Hallam-Baker wrote: >> Here we are all agreed that it is generally a bad thing for there to >> be this particular hole. That is not the issue. The issue is whether >> ignoring the fact that there are regulatory requirements for this >> capability and not supporting them results in a better or a worse >> outcome for users. >> >> So far the evidence suggests that refusal to consider them has >> resulted in a worse outcome. > > I agree, but I don't really understand why everyone's arguing. =A0It all > seems to be tangent to the purpose of all the working groups I've > seen, because ultimately, it's left at the discretion of the > implementations. > > A:"We shouldn't enable MITM under any circumstances!" =A0B:"Okay, do you > want to outlaw local trust databases?" A:"No, that's implementation > details." =A0B:"Yea but.... that's how MITM works." > or > A:"We shouldn't talk about MITM in the protocol!" B:"Okay, but people > are going to do it. Maybe we should have guidelines so users are > notified?" A:"No!" C:"Isn't that up to the browser?" B:"Oh, yea." > > The only argument I could see worth debating is somehow _enabling_ > MITM in the TLS protocol *itself*. =A0And not only do I think that's a > huuuge change, super-dangerous, I also think it's entirely > unnecessary, because we already have a viable, working MITM solution: > local trust stores. > > It seems to be a simple question: Will whatever "CA > Solution/Improvement" we come up be expected to override local, > user-set (or corporate IT-set) policy? =A0If no, MITM will work - don't > worry about it. =A0If so, how do you expect to accomplish that, when I > control everything on my machine?[2] > > -tom > > > [0] Burp and Fiddler are proxies designed for fiddling with HTTP > requests and responses > [1] Mallory is designed to muck about with raw TCP packets > [2] It *is* worth noting that the local policy engine/mechanism then > becomes ripe for attack, and instead of compromising CAs, we'll see > attacks that exploit bugs in it. =A0But, we can deal with that. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey --=20 Website: http://hallambaker.com/ From nico@cryptonector.com Thu Feb 16 10:16:39 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D054F11E8074 for ; Thu, 16 Feb 2012 10:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RF5ucuwaZMJh for ; Thu, 16 Feb 2012 10:16:35 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id C50F621E800C for ; Thu, 16 Feb 2012 10:16:35 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id DE4F877805F for ; Thu, 16 Feb 2012 10:16:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=KA8vJqY2UQrOb7wBVtdzQ ag7N5yaSaP40KLn4L2bkHt9l/uk2LUibzhHF7MCbbhPHjcsiEhyv3EsGkUbYRsb6 +06Ay2656iyz/jtm/gV0EQwnaRYNr97nHWrkN1PZf/tds6G3G3fng5NS8+w907j9 jZq3PeZtfH+BC0djmZT79I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=VJHtcXCuBPNlyyS+w5KT NSvbamA=; b=o7qQs7pvi5eJ9b+3NUBEnbncUFhdPPRv3+R6wqv7pfWAZRFeeS3V DggGmcOMAmHYX68H4GbF82k7VFoifC59HxvZbGnjEbVi0Rv7+Z5MwVnAJJNYfU9J 0Hpf0SAEbf3xt8Mg0SNk3wKBWa19I1vtanCxsG8lpIuDsX0cvgb3SWQ= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id C43FA77801D for ; Thu, 16 Feb 2012 10:16:34 -0800 (PST) Received: by dakl33 with SMTP id l33so2438510dak.31 for ; Thu, 16 Feb 2012 10:16:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.208.228 with SMTP id mh4mr16200105pbc.13.1329416194445; Thu, 16 Feb 2012 10:16:34 -0800 (PST) Received: by 10.68.136.4 with HTTP; Thu, 16 Feb 2012 10:16:34 -0800 (PST) In-Reply-To: References: <201202160430.q1G4UKY1000348@fs4113.wdf.sap.corp> Date: Thu, 16 Feb 2012 12:16:34 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: therightkey@ietf.org, mrex@sap.com, Kyle Hamilton , stephen.farrell@cs.tcd.ie Subject: Re: [therightkey] Secure e-mail, X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:16:40 -0000 On Thu, Feb 16, 2012 at 8:13 AM, Phillip Hallam-Baker wrote: > That works really well in the O/S world because in practice you can't > stop a policy enforcement point from being a potential point of > failure. The reason I dislike the peering model is that instead of one > single point of failure you end up with fifty single points of > failure. > > If Alice has her private key on every device that can read email then > the loss of any one of those devices exposes her key and all the > emails. You seem gung-ho on abandoning the end-to-end model. I understand the reasoning, and in the case of e-mail accept it fully, but I don't understand why we can't have a hybrid in the web case. A hybrid uses !end-to-end to security bootstrap end-to-end security. Note also that if all users get personal domainnames, like you and I and another .01% of users, then we can have end-to-end secure e-mail between personal domains once we boostrap end-to-end relationships between them (a big caveat, that, because most likely there will be a multi-hop PKI trust path only, certainly to begin with). The ends here would be servers in closets, sure, but they are suitable ends because they are the users' servers, not some other organization's. Nico -- From dkg@fifthhorseman.net Thu Feb 16 10:17:07 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C70221E803F for ; Thu, 16 Feb 2012 10:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTT6Y5HRD5d6 for ; Thu, 16 Feb 2012 10:17:06 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A2EEF21E803C for ; Thu, 16 Feb 2012 10:17:06 -0800 (PST) Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 77B9FF970; Thu, 16 Feb 2012 13:17:02 -0500 (EST) Message-ID: <4F3D481E.40001@fifthhorseman.net> Date: Thu, 16 Feb 2012 13:17:02 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20120125 Icedove/9.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org, Tom Ritter Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:17:07 -0000 On 02/16/2012 11:18 AM, Phillip Hallam-Baker wrote: > All that I have seen proposed in this regard is to have a draft that states: > > 1) This is a really bad idea in general > 2) If you really have to do it then do it this way > 2a) It is turned off by default > 2b) It only permits the authorized MITM to intercept > 2c) The user is repeatedly warned that MITM is taking place > 2d) There is no way that any credentials or infrastructure created for > authorized intercept can be used to support unauthorized intercept eh? it seems you're proposing a new mechanism, when Tom just pointed out that the existing mechanism (endpoint-controlled trust policy) already works for nearly every case. (the exceptions being client-side certs, and the hassle for IT staff of having to configure trust stores on each client) > I would rather have a defined path for this than to see another > iteration where the primary goal is to minimize the effort required > for the IT staff deploying the system. IT staff already have a simple way to do this: embed a MITM-enabling root authority (or comparable mechanism) in the client's trust policy. Who exactly is trying to "minimize the effort required for the IT staff" to deploy a MITM? I can't believe that on a list titled "the right key" the majority of the debate seems to be around whether we want a spec that enables transparent MITMing or a spec that enables user-visible MITMing. Which part of "the right key" does any sort of MITM fit into? The main argument seems to be "people need to do this for legal reasons" -- well, ok, let's have someone with a legal requirement for eavesdropping/monitoring step forward and propose an external, session-key-sharing mechanism that is *separate* from TLS. Then IT staff can deploy such a system on the clients they're required to monitor. If someone has a legal requirement to not only snoop but to alter traffic in flight beyond just terminating a session (i find this implausible, but what do i know), this can also be proposed as a separate mechanism, outside of TLS, or as a TLS extension. I don't see how it's appropriate for this list, though. Can we get back to discussing how to get the actual "right key" for the network peer? --dkg From paul@marvell.com Thu Feb 16 10:23:28 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A613B21F85B9 for ; Thu, 16 Feb 2012 10:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMAnYrggwgCo for ; Thu, 16 Feb 2012 10:23:28 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id D434A21F8499 for ; Thu, 16 Feb 2012 10:23:27 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTz1Jm74Ly38mwTiHCn9W2gF3yCibsilF@postini.com; Thu, 16 Feb 2012 10:23:27 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Thu, 16 Feb 2012 10:22:24 -0800 From: Paul Lambert To: "mrex@sap.com" Date: Thu, 16 Feb 2012 10:22:23 -0800 Thread-Topic: [therightkey] Basically, it's about keeping the CAs honest Thread-Index: AczsZg5bOXOq3cdhS9uWyqPA5lLDFQAbbXRA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579DA18FE@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01579DA14D8@SC-VEXCH2.marvell.com> from "Paul Lambert" at Feb 14, 12 07:04:09 pm <201202160447.q1G4l8rN001273@fs4113.wdf.sap.corp> In-Reply-To: <201202160447.q1G4l8rN001273@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nico@cryptonector.com" , "therightkey@ietf.org" , "aerowolf@gmail.com" Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:23:28 -0000 >> I notice you're still attaching a root certificate of unknown >> quality as part of your signature. Since it is different than my >> current class 2 root for the same named authority it may or may >> not be valid. If I accept your certificate and root I'm potentially >> at risk that you will later maliciously create MITM certs. > >Why do you care about the CA cert that signed Kyle's cert AT ALL? >If you don't recognize that CA cert, they you should continue to >completely >ignore that CA cert. If your MUA does not let you pin Kyle's cert >alone (for the purpose of verifying the signaturs on Kyles Emails), >but requires you to add cert of _his_ certifcation chain to add to >your trust anchors as a prerequisite for S/Mime signature verification, >then the PKI software used by your MUA is seriously broken. The user interface on my MUA (designed by one of the world's largest softwa= re companies) is unable to indicate to me what I should do with the two cer= tificates in a clear manner. On importing the first certificate - it indic= ates that it will be used for both e-mail and internet. Hence my prior com= plaint about possible vulnerabilities with cert acceptance. =20 Info on the cert from MS Outlook MUA Protects e-mail messages Ensures software came from software publisher Protects software from alteration after publication Allows data to be signed with the current time Allows data on disk to be encrypted Allows secure communication on the Internet <----- my issue in prior th= read Deep in the MS controls I can finally find check boxes to turn off everythi= ng but the email. I doubt that any but the most rabid security geek would = bother. Even then, it's very difficult to maintain the large number of cer= ts. The relationships and associated privileges are difficult to view revi= ew for security. With effort I could make this work ... the security and usability are of du= bious quality without very careful configuration. Also - cleaning up after my experiment, I disable both certs in the path fo= r the user cert, and the UI tells me the terminal cert is still valid! WE = seem to have a mixture of bad implementations - and technologies that are t= oo complicated in their details to make them easy to use. =20 Finally - there are no user centric constraints. The newly accepted cert c= an issue for any email or dns address. I can not place any limitations on = the new cert. Paul >-Martin From hallam@gmail.com Thu Feb 16 10:42:01 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A810311E8089 for ; Thu, 16 Feb 2012 10:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPDBAU0U0EMk for ; Thu, 16 Feb 2012 10:41:57 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF7E511E8074 for ; Thu, 16 Feb 2012 10:41:56 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3868358obb.31 for ; Thu, 16 Feb 2012 10:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CHRXxxcg+g5ZbjW9m3pkTiJH5O/Vu3O9s7r89nPtx/0=; b=g4xd/noSkQWbRj567Vu6x1OBCwHglKTAObENm2bRJ9VQx/fJ82nl/uLG+1xdRJzIOQ eV5Hu+eBGlxS12AOuqtYoIvlYoZA9vrx+tmHOeEjYVLbLmG7QprMN+xzEFYj7UYAgOaJ y65ZKTb5gC71taIRLgtaY2RcacwojPL5sbjGM= MIME-Version: 1.0 Received: by 10.182.160.37 with SMTP id xh5mr2711303obb.29.1329417716496; Thu, 16 Feb 2012 10:41:56 -0800 (PST) Received: by 10.182.75.138 with HTTP; Thu, 16 Feb 2012 10:41:56 -0800 (PST) In-Reply-To: <4F3D481E.40001@fifthhorseman.net> References: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp> <4F3D481E.40001@fifthhorseman.net> Date: Thu, 16 Feb 2012 13:41:56 -0500 Message-ID: From: Phillip Hallam-Baker To: Daniel Kahn Gillmor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: therightkey@ietf.org, Tom Ritter Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:42:01 -0000 On Thu, Feb 16, 2012 at 1:17 PM, Daniel Kahn Gillmor wrote: > On 02/16/2012 11:18 AM, Phillip Hallam-Baker wrote: >> All that I have seen proposed in this regard is to have a draft that sta= tes: >> >> 1) This is a really bad idea in general >> 2) If you really have to do it then do it this way >> 2a) It is turned off by default >> 2b) It only permits the authorized MITM to intercept >> 2c) The user is repeatedly warned that MITM is taking place >> 2d) There is no way that any credentials or infrastructure created for >> authorized intercept can be used to support unauthorized intercept > > eh? =A0it seems you're proposing a new mechanism, when Tom just pointed > out that the existing mechanism (endpoint-controlled trust policy) > already works for nearly every case. =A0(the exceptions being client-side > certs, and the hassle for IT staff of having to configure trust stores > on each client) > >> I would rather have a defined path for this than to see another >> iteration where the primary goal is to minimize the effort required >> for the IT staff deploying the system. > > IT staff already have a simple way to do this: embed a MITM-enabling > root authority (or comparable mechanism) in the client's trust policy. It is a solution to the IT depts problem but there isn't transparency for the user. The user is not told that they are being MITM'd. Further, if DANE was deployed or any of the proposals made here was deployed they would stop the MITM enabling root authority from working. So we are proposing to break the escape hole you are proposing they use. Now breaking that escape hole might be a good thing. But we should certainly think about the consequences and it should be a deliberate decision to break it and not provide an alternative. > Who exactly is trying to "minimize the effort required for the IT staff" > to deploy a MITM? BlueCoat did. > I can't believe that on a list titled "the right key" the majority of > the debate seems to be around whether we want a spec that enables > transparent MITMing or a spec that enables user-visible MITMing. =A0Which > part of "the right key" does any sort of MITM fit into? One of the requirements that drives this work is that people did this in the past and did it in a very bad way. So we need to either tell them not to do it again or work out a safe way for them to do it. > The main argument seems to be "people need to do this for legal reasons" > -- well, ok, let's have someone with a legal requirement for > eavesdropping/monitoring step forward and propose an external, > session-key-sharing mechanism that is *separate* from TLS. =A0Then IT > staff can deploy such a system on the clients they're required to monitor= . And how does that work? Saying that 'it should be separate' does not absolve you from proposing how it would work. If you are putting a proposal on the table then it needs to be either 'don't do it at all' or 'this is how to do it', I can't see how 'let someone else do it' helps us. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Thu Feb 16 10:49:14 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0A811E80B0 for ; Thu, 16 Feb 2012 10:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTz7iGcnrchl for ; Thu, 16 Feb 2012 10:49:10 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 208CE11E80AE for ; Thu, 16 Feb 2012 10:49:10 -0800 (PST) Received: by obbwd15 with SMTP id wd15so3877202obb.31 for ; Thu, 16 Feb 2012 10:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OxX1/LUH1Gwde+aHflOuegohbqpmbZ6idd7fa6vcGAo=; b=v0zRbs3wMzSr+MhVA4wN5dE5BKzLKoqROYHO6+kHf2RgM5VWBq3capATICmLcoUUYC jUtZ15sbD75LQEnC3tCTbBDyjl7Ai6t9yw1ZPllaLW1YgXMxKuwmzfvQQOdQ6cXmppbY WB7/t3hnOUamiNSTdvekxap5NenBbI5zcKg84= MIME-Version: 1.0 Received: by 10.182.160.37 with SMTP id xh5mr2726010obb.29.1329418149436; Thu, 16 Feb 2012 10:49:09 -0800 (PST) Received: by 10.182.75.138 with HTTP; Thu, 16 Feb 2012 10:49:09 -0800 (PST) In-Reply-To: References: <201202160430.q1G4UKY1000348@fs4113.wdf.sap.corp> Date: Thu, 16 Feb 2012 13:49:09 -0500 Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: therightkey@ietf.org, mrex@sap.com, Kyle Hamilton , stephen.farrell@cs.tcd.ie Subject: Re: [therightkey] Secure e-mail, X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:49:14 -0000 I have been saying this for five or six year now, that is hardly gung ho. And I have discussed it at length with the people behind the original end to end model. What I am saying is that the design of a security protocol needs to come from an analysis of risks and of the constraints imposed by users, legacy technology, etc. If the approach that happens to minimize residual risk in practice is end to end, then fine, go with it. But 'must be end to end' has no place in a requirements document. Remember that SSL was very different from the designs that I proposed, EKR and Shiffman proposed and everyone in IETF land was considering. It broke with the current dogma in very significant ways. Now in retrospect, those breaks turn out to have been critical for the success of SSL. On Thu, Feb 16, 2012 at 1:16 PM, Nico Williams wrot= e: > On Thu, Feb 16, 2012 at 8:13 AM, Phillip Hallam-Baker = wrote: >> That works really well in the O/S world because in practice you can't >> stop a policy enforcement point from being a potential point of >> failure. The reason I dislike the peering model is that instead of one >> single point of failure you end up with fifty single points of >> failure. >> >> If Alice has her private key on every device that can read email then >> the loss of any one of those devices exposes her key and all the >> emails. > > You seem gung-ho on abandoning the end-to-end model. =A0I understand the > reasoning, and in the case of e-mail accept it fully, but I don't > understand why we can't have a hybrid in the web case. =A0A hybrid uses > !end-to-end to security bootstrap end-to-end security. > > Note also that if all users get personal domainnames, like you and I > and another .01% of users, then we can have end-to-end secure e-mail > between personal domains once we boostrap end-to-end relationships > between them (a big caveat, that, because most likely there will be a > multi-hop PKI trust path only, certainly to begin with). =A0The ends > here would be servers in closets, sure, but they are suitable ends > because they are the users' servers, not some other organization's. > > Nico > -- --=20 Website: http://hallambaker.com/ From tom@ritter.vg Thu Feb 16 11:25:14 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B70321F87A1 for ; Thu, 16 Feb 2012 11:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzZfAf0HKHAm for ; Thu, 16 Feb 2012 11:25:09 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 382C521E8081 for ; Thu, 16 Feb 2012 11:25:09 -0800 (PST) Received: by lahl5 with SMTP id l5so3249594lah.31 for ; Thu, 16 Feb 2012 11:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9iOBHd6w59PCEpt6erpzf2RIAIW0YaOIrvpbObRJVI0=; b=1fgrUh5ix6fPm4zzQciWzHca+G3uvqHNexGFvERqyg0RA/KclOOsS6sm3fq9X8VxnQ ZdE72BY/WfHQ08FhQhbnjzdB/+hvFsOJMrbBQ8T/X9Og/EV1KtcEbWl/c4a7g1eGOJkr WXCnAKS6ntgrEbXOJplUrFlmgjlioY73hDk04= Received: by 10.152.114.74 with SMTP id je10mr2999287lab.40.1329420308089; Thu, 16 Feb 2012 11:25:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.38.4 with HTTP; Thu, 16 Feb 2012 11:24:48 -0800 (PST) In-Reply-To: References: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp> <4F3D481E.40001@fifthhorseman.net> From: Tom Ritter Date: Thu, 16 Feb 2012 14:24:48 -0500 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQliVJ//2POXT3FGTf+e1H6NIalSmAXaCHptOoTF/NjM740BxM3G+sbvj4FlwLJ9YO6Kde8K Cc: therightkey@ietf.org, Daniel Kahn Gillmor Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:25:14 -0000 On 16 February 2012 13:41, Phillip Hallam-Baker wrote: > Further, if DANE was deployed or any of the proposals made here was > deployed they would stop the MITM enabling root authority from > working. So we are proposing to break the escape hole you are > proposing they use. > > Now breaking that escape hole might be a good thing. But we should > certainly think about the consequences and it should be a deliberate > decision to break it and not provide an alternative. We just had this same discussion on DANE: http://www.ietf.org/mail-archive/web/dane/current/msg04306.html I raised the same point about local policy enabling an override, and the consensus seemed to be: "That's a good point, and mandating what clients do is not the spec's problem. Let's propose good solutions for browsers offline/out of the WG." A nice side effect was that a locally configured trust anchor overriding a TLSA enables valid corporate MITM, while a non-transparent, shady-trustwave-style-subca would not be overridden by local policy, and the TLSA would cause a hard fail. I'd also like to go on the record that I think a visual indicator to the user that shows a cert is valid only under local policy is a fantastic idea and I support it wholeheartedly. Of course UI is hard, especially with this opaque a topic to an average user, but I still think giving it a shot is a good idea. -tom From dkg@fifthhorseman.net Thu Feb 16 11:57:20 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7B721E80A7 for ; Thu, 16 Feb 2012 11:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHdzTcGi3u4O for ; Thu, 16 Feb 2012 11:57:19 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0973321E809D for ; Thu, 16 Feb 2012 11:57:18 -0800 (PST) Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 164E3F970; Thu, 16 Feb 2012 14:57:17 -0500 (EST) Message-ID: <4F3D5F9D.3040101@fifthhorseman.net> Date: Thu, 16 Feb 2012 14:57:17 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20120125 Icedove/9.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp> <4F3D481E.40001@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org, Tom Ritter Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 19:57:20 -0000 On 02/16/2012 01:41 PM, Phillip Hallam-Baker wrote: > On Thu, Feb 16, 2012 at 1:17 PM, Daniel Kahn Gillmor wrote: >> The main argument seems to be "people need to do this for legal reasons" >> -- well, ok, let's have someone with a legal requirement for >> eavesdropping/monitoring step forward and propose an external, >> session-key-sharing mechanism that is *separate* from TLS. Then IT >> staff can deploy such a system on the clients they're required to monitor. > > And how does that work? > > Saying that 'it should be separate' does not absolve you from > proposing how it would work. If you are putting a proposal on the > table then it needs to be either 'don't do it at all' or 'this is how > to do it', I can't see how 'let someone else do it' helps us. I'm not about to spend my own time writing this up, since i agree with you that doing an MITM is a bad idea in general. But the concept of sharing the session keys of a TLS connection with a third party so they can listen in isn't some genius feat of invention, and someone sufficiently motivated to do so could write up such a spec. But that's not to say that it's in-scope for discussion on this list. We could also discuss ways that TLS hurts the environment by being overly wasteful of CPU cycles (and how to improve things there). That might also be an interesting discussion, but it isn't germane to finding "the right key", so it doesn't belong on this list. Regards, --dkg From paul@marvell.com Thu Feb 16 13:32:15 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB1821E808E for ; Thu, 16 Feb 2012 13:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVGjwNNTFP7l for ; Thu, 16 Feb 2012 13:32:11 -0800 (PST) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id F137A21E8052 for ; Thu, 16 Feb 2012 13:32:09 -0800 (PST) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTz1117q0Ahkxr62KHk485tAnAvbTa7JT@postini.com; Thu, 16 Feb 2012 13:32:11 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Thu, 16 Feb 2012 13:29:01 -0800 From: Paul Lambert To: Tom Ritter , Phillip Hallam-Baker Date: Thu, 16 Feb 2012 13:29:00 -0800 Thread-Topic: [therightkey] Basically, it's about keeping the CAs honest Thread-Index: Aczs4La/DFurP5cYTZW0SDigmZlLSQAEMuFQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579DA1995@SC-VEXCH2.marvell.com> References: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp> <4F3D481E.40001@fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "therightkey@ietf.org" , Daniel Kahn Gillmor Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:32:15 -0000 >I'd also like to go on the record that I think a visual indicator to >the user that shows a cert is valid only under local policy is a >fantastic idea and I support it wholeheartedly. Of course UI is hard, >especially with this opaque a topic to an average user, but I still >think giving it a shot is a good idea. A similar usage of colors - with poor results: http://www.usablesecurity.org/papers/jackson.pdf=20 Is local policy more or less secure to the user? I'd say more ... From hallam@gmail.com Thu Feb 16 13:50:37 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E48E21E801C for ; Thu, 16 Feb 2012 13:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.404 X-Spam-Level: X-Spam-Status: No, score=-3.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdtqDJ8gC5Bp for ; Thu, 16 Feb 2012 13:50:31 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09BB721E8019 for ; Thu, 16 Feb 2012 13:50:30 -0800 (PST) Received: by obbwd15 with SMTP id wd15so4090357obb.31 for ; Thu, 16 Feb 2012 13:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vQ2tvaVRCOCV8QkW/3RGLMdTLRiZbfOxrXQDkE8u8dM=; b=VoqIkGFdDdYjPLZerbVPv1gBm/1CERnuvabqk6eX3GG8YoRflMRGrFd8uCJlW0mu+1 lEx7YDB/kIa27ogBwiMNpA6NtRkMjAnE0Kk9R1gMJsClHoC0hqrxxPhnoU13tHiuCJ9O 5ZO5b5ZLhlBANMq6e/BP7ngYb0qYr9E8l92qU= MIME-Version: 1.0 Received: by 10.182.75.102 with SMTP id b6mr3225990obw.9.1329429029900; Thu, 16 Feb 2012 13:50:29 -0800 (PST) Received: by 10.182.75.138 with HTTP; Thu, 16 Feb 2012 13:50:29 -0800 (PST) In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01579DA1995@SC-VEXCH2.marvell.com> References: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp> <4F3D481E.40001@fifthhorseman.net> <7BAC95F5A7E67643AAFB2C31BEE662D01579DA1995@SC-VEXCH2.marvell.com> Date: Thu, 16 Feb 2012 16:50:29 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Lambert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" , Tom Ritter , Daniel Kahn Gillmor Subject: Re: [therightkey] Basically, it's about keeping the CAs honest X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 21:50:38 -0000 I don't trust the results of lab usability studies. One of the big problems is that a subject comes into a lab expecting to see stuff that is flaky. So they are primed to ignore warnings. Another side of this is that usability methodology has been developed to sell stuff. That is why the priority for Apple was to get the user comfortable in 15 mins. That is a typical length for a sales pitch. The whole usability world has evolved around the first impression of the user and not the long term response. But the academics are really happy with a paradigm that allows them to get papers published on the basis of cheap, easy to run studies. I agree that a security signal needs to be much more than a different address bar color. I would take over the whole browser window for a transitional. On Thu, Feb 16, 2012 at 4:29 PM, Paul Lambert wrote: > > > > >>I'd also like to go on the record that I think a visual indicator to >>the user that shows a cert is valid only under local policy is a >>fantastic idea and I support it wholeheartedly. =A0Of course UI is hard, >>especially with this opaque a topic to an average user, but I still >>think giving it a shot is a good idea. > > A similar usage of colors - with poor results: > http://www.usablesecurity.org/papers/jackson.pdf > > Is local policy more or less secure to the user? =A0I'd say more ... --=20 Website: http://hallambaker.com/ From kent@bbn.com Thu Feb 16 15:12:00 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D64121E8051 for ; Thu, 16 Feb 2012 15:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.237 X-Spam-Level: X-Spam-Status: No, score=-105.237 tagged_above=-999 required=5 tests=[AWL=-1.238, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D08Kp6QO7LhX for ; Thu, 16 Feb 2012 15:11:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 65F5F21F8633 for ; Thu, 16 Feb 2012 15:11:59 -0800 (PST) Received: from dhcp89-089-114.bbn.com ([128.89.89.114]:49158) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RyAUT-000Hh8-5g; Thu, 16 Feb 2012 18:11:53 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 16 Feb 2012 18:11:47 -0500 To: "Kyle Hamilton" From: Stephen Kent Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Cc: Joe St Sauver , "therightkey@ietf.org" , DIEGO LOPEZ GARCIA Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:12:00 -0000 At 6:12 PM -0800 2/10/12, Kyle Hamilton wrote: >On Thu, Feb 9, 2012 at 3:05 PM, Stephen Kent wrote: >>At 11:29 PM +0100 2/9/12, DIEGO LOPEZ GARCIA wrote: >>> >...and I do agree with you in that whichever entity making such >>>assertion (X.509, SAML, JWT=B7) has to be authoritative for the identity >>>asserted if you want it to be usable. >>I think we are in agreement. CAs that are not authoritative for asserted >>identities are as bad as federated trust entities with similar properties. > >What are these 'identities' that need to be=20 >asserted with authoritative backing? I hope=20 >you're not just talking about state identities,=20 >even though state identity is an important part=20 >of it. The current crop of authoritative=20 >information CAs are very good at two things:=20 >they know how to authenticate documents, and=20 >they know how to authenticate authority (defined=20 >as 'a state', or 'the government of a state').=20 >They are probably, in that respect, even better=20 >than State Department employees. I fear that you're not paying close attention to what I said, Kyle. >US Federal don't want to get involved with=20 >providing a service to every citizen. They=20 >would rather foster the development of a private=20 >authentication service industry, and accredit=20 >it. No matter what we might believe is=20 >"correct" from a purely theoretical view, US=20 >Federal Bridge PKI has cross-certified Verisign,=20 >Verizon/Cybertrust, Operational Research=20 >Consultants Inc, and Entrust. On top of this,=20 >aerospace contractors often have their own=20 >certifiers, who are delegated similar Authority.=20 >Ironically, this Authority is currently not=20 >recognized by user software. yes, the Federal bridge CA is a bad idea, as implemented. >But the reason why I don't want to get hung up=20 >on state identities is because clubs need to=20 >have their own identities, too. Virtual clubs=20 >and forums need to have theirs too, and it's=20 >common practice to fill out forum signup forms=20 >with bogus information because the forums=20 >typically don't actually need real identity=20 >information. Trying to insist that the DN be=20 >matched solely from an authoritative CA violates=20 >this "principle of least privilege", which means=20 >that people can't use authoritative CAs if they=20 >want to protect their personal information from=20 >identity thieves and still communicate over the=20 >network. I'm not talking about 'state" identities in most cases. Look at the IDs associated with most of the credentials that you=20 hold. They include your name and a number. Your=20 name is not globally unique, but a name plus a=20 number managed by the authority IS unique,=20 relative to that authority. This applies to=20 credit cards, driver's licenses, frequent=20 traveller cards, and passports. Steve From kent@bbn.com Thu Feb 16 15:12:01 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B703221F8633 for ; Thu, 16 Feb 2012 15:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.464 X-Spam-Level: X-Spam-Status: No, score=-106.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiUf7s3gxBRW for ; Thu, 16 Feb 2012 15:12:01 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6EE21F8617 for ; Thu, 16 Feb 2012 15:12:01 -0800 (PST) Received: from dhcp89-089-114.bbn.com ([128.89.89.114]:49159) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RyAUa-000HhH-F8; Thu, 16 Feb 2012 18:12:00 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 16 Feb 2012 18:11:58 -0500 To: "Kyle Hamilton" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: therightkey@ietf.org, Phillip Hallam-Baker Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:12:01 -0000 At 11:02 PM -0800 2/9/12, Kyle Hamilton wrote: >On Wed, Feb 8, 2012 at 9:06 AM, Stephen Kent wrote: >>So, I don't agree that the distinction between the user and a machine >>operated by a user is really significant, in the end. (Yes, I am ware of >>the many security problems that arise because the user doesn't really know >>what the code is doing, but nothing is perfect.) > >I believe that there's a very good reason to separate them. We're >going to need to move to a system where we have effectively a >separate UID per application, within the overarching user's UID. >This is the only effective way to isolate the damage which one >application can cause, and the only effective way to audit precisely >which application did what damage. I appreciate the potential benefit for per-app IDs vs. user/machine IDs, but given the sorry state of OS secruity, it's not clear that a per-app ID is really meaningful. >This is a recasting of Android's model, where the "user ID" is "the >device's controller", and the applications themselves are assigned >Linux UIDs so they can't interfere with each other. > >>I agree that credential portability is essential. [...] > >Credential portability is overrated. The real problem is credential >equivalence. PHB pointed out why credential portability is critical for encrypted e-mail. For many other apps, it is not so critical. I am not sure that equivalence is a good alternative, as mapping among multiple credentials creates an opportunity for additional secruity problems. > >>>S/MIME with a private key shared to fifteen devices no longer looks >>>very secure to me. > >S/MIME with a private key stored on a daemon system and unique >private keys on each of fourteen accessing clients, on the other >hand... is not e-2-e secure and this less desirable. > >>Crednetial portability does not necessarily imply a private key kept in SW >>in every device. > >Credential portability does, however, imply a private key or other >authenticator must be handled in SW in every device. Intermittent >security is harder than complete security in a sufficiently complex >system. not true. many folks carry devices that could be used to store private keys that are used briefly, to unwrap keys. Steve From hallam@gmail.com Thu Feb 16 15:29:43 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8100D21E8035 for ; Thu, 16 Feb 2012 15:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PgklrHL6y9Y for ; Thu, 16 Feb 2012 15:29:39 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09C8F21E8025 for ; Thu, 16 Feb 2012 15:29:38 -0800 (PST) Received: by obbwd15 with SMTP id wd15so4206447obb.31 for ; Thu, 16 Feb 2012 15:29:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cb22T91hEibNig2BjUPp132sp9gZWSyb4JG/4vu1H8A=; b=SV0vULDlgvponEZMsQ5BMHf0xszWdhBPlWRxS6oVy5zzXofxxZBSfSVWWwOuLQRWjW aGU0oUX4vynPiiuLt+Zpi9hdr5ESNUt3n8B1PuS3fBcbfVVrv6mHOrX6uwpEjMCpKagE Umxr/bDrN/MGDNoBMy1S7hzBmiKeuuqJgOixE= MIME-Version: 1.0 Received: by 10.60.1.137 with SMTP id 9mr1631055oem.39.1329434978419; Thu, 16 Feb 2012 15:29:38 -0800 (PST) Received: by 10.182.75.138 with HTTP; Thu, 16 Feb 2012 15:29:38 -0800 (PST) In-Reply-To: References: Date: Thu, 16 Feb 2012 18:29:38 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: therightkey@ietf.org, Kyle Hamilton Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 23:29:43 -0000 Credential equivalence is not for every application. In particular there are cases where you want a user to have exactly one physical credential and that is a part of the security scheme. But I still think that the rule of 'private keys never move outside the device once they are in' is a good one and one we could stick to.There are some use cases for which generating the keys on the device is not practical but I still think a different key per device and no movement of the key from one device to another is a good plan. So in this approach Alice would have Alice S/MIME private key corresponding to public key in cert (located at se= rver) Alice 1 (desktop) Alice 2 (cell phone) ... Alice n (whatev) If Alice is going to read an encrypted email on a given device it asks the server to decrypt the session key and reencrypt it under the device key. Now people can say this is not true end to end, but have we really increased the number of possible points of vulnerability? So the server can be compromised, but so what? The endpoint can be compromised much more easily. On Thu, Feb 16, 2012 at 6:11 PM, Stephen Kent wrote: > At 11:02 PM -0800 2/9/12, Kyle Hamilton wrote: >> >> On Wed, Feb 8, 2012 at 9:06 AM, Stephen Kent wrote: >>> >>> So, I don't agree that the distinction between the user and a machine >>> operated by a user is really significant, in the end. =A0(Yes, I am war= e of >>> the many security problems that arise because the user doesn't really >>> know >>> what the code is doing, but nothing is perfect.) >> >> >> I believe that there's a very good reason to separate them. =A0We're goi= ng >> to need to move to a system where we have effectively a separate UID per >> application, within the overarching user's UID. This is the only effecti= ve >> way to isolate the damage which one application can cause, and the only >> effective way to audit precisely which application did what damage. > > > I appreciate the potential benefit for per-app IDs vs. user/machine IDs, = but > given the sorry state of OS secruity, it's not clear that a per-app ID is > really meaningful. > > >> This is a recasting of Android's model, where the "user ID" is "the >> device's controller", and the applications themselves are assigned Linux >> UIDs so they can't interfere with each other. >> >>> I agree that credential portability is essential. [...] >> >> >> Credential portability is overrated. =A0The real problem is credential >> equivalence. > > > PHB pointed out why credential portability is critical for encrypted e-ma= il. > For many other apps, it is not so critical. I am not sure that equivalenc= e > is a good alternative, as mapping among multiple credentials creates an > opportunity for additional secruity problems. > > >> >>>> S/MIME with a private key shared to fifteen devices no longer looks >>>> very secure to me. >> >> >> S/MIME with a private key stored on a daemon system and unique private >> keys on each of fourteen accessing clients, on the other hand... > > > is not e-2-e secure and this less desirable. > > >> >>> Crednetial portability does not necessarily imply a private key kept in >>> SW >>> in =A0every device. >> >> >> Credential portability does, however, imply a private key or other >> authenticator must be handled in SW in every device. =A0Intermittent sec= urity >> is harder than complete security in a sufficiently complex system. > > > not true. many folks carry devices that could be used to store private ke= ys > that are used briefly, to unwrap keys. > > Steve --=20 Website: http://hallambaker.com/ From aerowolf@gmail.com Thu Feb 16 19:50:31 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EB721E8081 for ; Thu, 16 Feb 2012 19:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=1.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvxuAUFX0yXB for ; Thu, 16 Feb 2012 19:50:30 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C82B21E806E for ; Thu, 16 Feb 2012 19:50:30 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so3414854pbc.31 for ; Thu, 16 Feb 2012 19:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=t7j6+QHLVzMwJALM/moEyl5K3hrSMPLcutjd7qlwV6I=; b=hs+sVjXkztbALahIMumQIvgle6XtIa2otXtAvVZhcY+jqVKcin1USTGdZXN2eDkkBH tSadTPKVkc0wAitMRGJ0RNnWn4TIuUAhtcQV0zvJzWSNm/E8rfXki8DnqQKU+erczqUY U7V2x5x2/Zl0xR0nFjmmhY4cxmx2sgs9Anvr8= Received: by 10.68.134.228 with SMTP id pn4mr20066130pbb.52.1329450630468; Thu, 16 Feb 2012 19:50:30 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id m5sm4014863pbo.69.2012.02.16.19.50.26 (version=SSLv3 cipher=OTHER); Thu, 16 Feb 2012 19:50:27 -0800 (PST) From: "Kyle Hamilton" To: "Stephen Kent" Date: Thu, 16 Feb 2012 19:50:30 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgyqokvypxdcrqyx2g22 Cc: Joe St Sauver , "therightkey@ietf.org" , DIEGO LOPEZ GARCIA Subject: Re: [therightkey] Will the real RPF please stand up? X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 03:50:31 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgyqokvypxdcrqyx2g22 Content-Type: text/plain; format=flowed; charset=us-ascii Content-Transfer-Encoding: 7bit On Thu, Feb 16, 2012 at 3:11 PM, Stephen Kent wrote: > yes, the Federal bridge CA is a bad idea, as implemented. Federal Bridge CA is a much better idea than what we have now. Currently, we have large numbers of absolutely-trusted roots with no controls on them other than ultimate distrust. Worse, we have no way to protect users from misbehaving ones other than software update pushes. We have no actual way to determine negligence except in light of what other people raise to us, and the people who are supposed to raise things to us don't know what to look for, what to tell us, or where to tell us. Negligence in private contracts is a fairly difficult thing to prove, and carries almost no penalty. FBCA has an ongoing audit and accreditation system (with heightened detection of failures due to GAO oversight), has a working revocation system, and only cross-certifies CAs run by people with a contract in place with a Federal entity. This makes the negligent violation of the terms of the Federal Common Certificate Policy a highly-detectable 10-20 year felony, with the ability to shut down the affected root without a software push. This is a better situation than the current lack of contracts in place with (e.g.) Mozilla, and is a much better threat than what we've got right now ('go out of business', not 'go to prison') once it's discovered. I don't understand. How is FBCA "a bad idea, as implemented"? > I'm not talking about 'state" identities in most cases. Look at the IDs > associated with most of the credentials that you hold. They include your > name and a number. Your name is not globally unique, but a name plus a > number managed by the authority IS unique, relative to that authority. This > applies to credit cards, driver's licenses, frequent traveller cards, and > passports. I acknowledge your point. Relative to local authorities (who are authoritative for their own realms of use and utility), the name is not an identifier at all. The name is metadata associated with the locally-authoritative identifier, which is the unique assigned record number you refer to. Local authorites aren't authoritative for legal names, but legal names appear in and on the credentials they issue. This is why a strict binary interpretation of certificates fails: only individual components of the atomic certificate are what the local authority is authoritative for. There is no single authority for everything. Many authorities are authoritative for different parts of a person's gestalt identity. Each individual authority needs to issue credentials that are useful to itself and its served users. And, many times multiple authorities are necessary to really get the job done. In addition, these credentials are often useful for other social things which don't involve the original local authority, like "has an American Express Black card" is often seen as a status symbol. -Kyle H --gmsm1.9.5eqgyqokvypxdcrqyx2g22 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTcwMzUwMzBaMCMGCSqGSIb3DQEJBDEWBBRVIjIV0NgmfvvPlWQGbmGu gP3w0jBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAM0uMDugRpJShBI2wutcRLaT48sQpg5nYBQwelumbizmCiO8wLOtFuh4b8IoJJQkmvHZc ZzmNEsXT4VWoCxtII9GGo7+/gMRbKI20ijFlbv3pn5hWkxp1/8fhpJXjMbCrXWNJAzrT0WYWBVNU JWRVXyZ5fMVpyRs8rBaAthw11zSArrss9yrZviX9F2XXiw/B4JmQbGO5paHzk8EddImYcLR7xy7I vjD8Oo9OsjJ/rJ2htc1LKPuu3Cd89TMe0JF33YpQol7xuAYqtCRS5CHFHxBP5KIOkJ+lpFCIrdzr c5XamgYSTTaz17rM7shv/MBBIZ0pehXR4IhBkFEK997wfQAAAAAAAA== --gmsm1.9.5eqgyqokvypxdcrqyx2g22-- From nico@cryptonector.com Fri Feb 17 12:37:44 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7691F0C4F for ; Fri, 17 Feb 2012 12:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHiBweEhfO3K for ; Fri, 17 Feb 2012 12:37:44 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDE21F0C4E for ; Fri, 17 Feb 2012 12:37:44 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 7BE5226406C for ; Fri, 17 Feb 2012 12:37:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=EhElhclzPZhzw11BTBPK0 gR8iOzU/yLrK6OpDY1aatNjebLGx/KS0/3og0dR7mY/IcNvSty5PMGFfK0psyW+F QQ8hj7oWLZTf5JxDf2Opk5TXDEWH5TgGEeH4A18uzs5lOXjgrjt7BR7nBaAL14eB HRFepCF4ypAYMYb5OiDG6c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=+pwO0f3pjwsTK8NkXzog ROJhvgs=; b=mm0EoC6yV16AVTuFdzIO7g6stKKsYXilqgX3joi6Wy3HomziZvX7 FmCK5O17iE3+5gmMGqc/a0mmObWxN/uyo+G258q23gWn0Ou2rv+ftwcuYaq0nU7Q gIgMiHN801npwpXpg53PLDMCikHl/d2B4QNCi6mwAuiBNrJk0rYWRDc= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 614CC264005 for ; Fri, 17 Feb 2012 12:37:43 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so4307033pbc.31 for ; Fri, 17 Feb 2012 12:37:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.136.198 with SMTP id qc6mr22157576pbb.160.1329511063151; Fri, 17 Feb 2012 12:37:43 -0800 (PST) Received: by 10.68.136.4 with HTTP; Fri, 17 Feb 2012 12:37:43 -0800 (PST) In-Reply-To: References: <4F3C04C9.7040601@cs.tcd.ie> <4F3D00D7.8020305@cs.tcd.ie> <4F3D0F0C.6010707@cs.tcd.ie> Date: Fri, 17 Feb 2012 14:37:43 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 20:37:45 -0000 On Thu, Feb 16, 2012 at 8:20 AM, Phillip Hallam-Baker wrote: > It would be really nice if there was some way to audit RNGs algorithmically... Separate the HW RNG and other entropy gathering parts from the rest of the RNG (i.e., the entropy pool, the mixer, the extractor), and you provide a per-device seed for testing. To test you put the device in test mode so that the only entropy will be from the test seed, thus making the RNG completely deterministic. The production mode can also use the test (or another per-device) seed and date/time of boot to initialize the entropy pool, just in case the HW RNG get stuck on all ones or all zeros (or all nines). Testing production mode can also be done by, e.g., statistical analysis of the RNG outputs (and inputs) under various operating conditions (e.g., different temperatures, etc...), and by extracting a copy of the entropy pool contents once to check that the RNG is not deterministic from that point forward (because new entropy gets mixed in). But you have to make sure that any test modes can't be enabled without tampering with the physical device. Once the device is sealed you should not be able to test the RNG in any way other than by statistical analysis of its outputs. Nico -- From hallam@gmail.com Fri Feb 17 14:51:33 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A515E11E80A5 for ; Fri, 17 Feb 2012 14:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5ukXXU5EpGe for ; Fri, 17 Feb 2012 14:51:27 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5320611E808D for ; Fri, 17 Feb 2012 14:51:27 -0800 (PST) Received: by obbwd15 with SMTP id wd15so5787224obb.31 for ; Fri, 17 Feb 2012 14:51:27 -0800 (PST) Received-SPF: pass (google.com: domain of hallam@gmail.com designates 10.182.1.104 as permitted sender) client-ip=10.182.1.104; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hallam@gmail.com designates 10.182.1.104 as permitted sender) smtp.mail=hallam@gmail.com; dkim=pass header.i=hallam@gmail.com Received: from mr.google.com ([10.182.1.104]) by 10.182.1.104 with SMTP id 8mr7373943obl.19.1329519087047 (num_hops = 1); Fri, 17 Feb 2012 14:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zd9329K+3y9vCZs/XvnDMNvJd2KVhxf13ia0V3UjfPw=; b=ch4CCPI9/lKRbX8QE/GhPz53iSEW17mw1kCNJmKmz8Idn7zNGoAytToF1saNqolUAi MczyTPfysQf0uwyy9yjy0jZAL6FrInnywjk276LB3E+2VSQ52S1UbeB1awoiSEwG6jpf jNNvbLDQPs/Ml8F/dZqTgd2x6HNmE7H+t33Tk= MIME-Version: 1.0 Received: by 10.182.1.104 with SMTP id 8mr6238266obl.19.1329519086984; Fri, 17 Feb 2012 14:51:26 -0800 (PST) Received: by 10.182.75.138 with HTTP; Fri, 17 Feb 2012 14:51:26 -0800 (PST) In-Reply-To: <4F3D12C4.3060901@cs.tcd.ie> References: <4F3C04C9.7040601@cs.tcd.ie> <4F3D00D7.8020305@cs.tcd.ie> <4F3D0F0C.6010707@cs.tcd.ie> <4F3D12C4.3060901@cs.tcd.ie> Date: Fri, 17 Feb 2012 17:51:26 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 22:51:33 -0000 I don't see how you get ergodicity into the device without the possibility of observation. Without addressing that problem you are going to have a protocol that always tells the client 'yep you are hosed'. I see the following possibilities for ergodicity 1) Random seed installed during manufacture 2) Random capture from embedded RNG source / environmental capture 3) Random caputure from UI 4) Obtain random data from the network For the web browser or server the usual approach is (3). It works fine because there is sufficient ergodicity in the UI interactions to provide 128 bits just waiting a few seconds. But we can't do that on an embedded device 1) Is actually not as bad as might be imagined, you trust the manufacturer not to backdoor your crypto so having them give you a seed is not terrible. 2) Is ideal but adds to hardware cost. Unless that is someone can work out a cheap way to get random data into a D/A port or other I/O pin. 4) Is clearly sub optimal since the service knows the data sent. How about this for a better protocol approach? Client generates random seeds. S1, S2 Client sends Trunc(H(S1)) to the service Service says 'hey I have seen that before' or 'nope it is new' + returns S3 Client generates new seed from H(S1 + S2 + S3 +c) Where c is a counter that is incremented for each call for more random bits= . Advantages: 1) The checking protocol is tied into the PRNG algorithm so that it is really hard for the programmer to balls it up. 2) Only part of the ergodicity is checked, the protocol checks to see that there are at least 128 bits worth of random data in the output. Cons: 1) Requires twice the amount of randomness to do the job right. A scheme of this type might well be best implemented as a canary type scheme so that issues the the PRNG during configuration were being detected... Also, this looks to me to be the sort of thing that you would want to be a part of some form of device enrollment protocol. On Thu, Feb 16, 2012 at 9:29 AM, Stephen Farrell wrote: > > > On 02/16/2012 02:20 PM, Phillip Hallam-Baker wrote: >> >> On Thu, Feb 16, 2012 at 9:13 AM, Stephen Farrell >> =A0wrote: >>> >>> >>> >>> On 02/16/2012 01:51 PM, Phillip Hallam-Baker wrote: >>>> >>>> >>>> My first thought was that this should be done by the CA. >>> >>> >>> >>> In the cited material, they also cover PGP and SSH keys and >>> not every CA will have a collection beyond its own end >>> entities so I don't think this is a CA function since its >>> not checking one public key, but one public key against >>> a population of keys and is independent of X.509, PGP, SSH >>> etc. >>> >>> >>>> Then it turns >>>> >>>> out that these are all (apparently) embedded systems generated keys >>>> and only some of those are CA certified. So maybe there is a need for >>>> this protocol. >>> >>> >>> >>> That too. >> >> >> Problem being that it is probably easier to implement a RNG right than >> to implement any additional protocol for checking. Or at least the >> only people who are likely to implement your protocol are people who >> (1) would do the RNG right or (2) are required to for an audit >> requirement. > > > A fair point. But one we don't seem to be able to get right > and there are to also be fair some subtleties. > > Apparently some of the problem is also not the PRNG algorithm, > but rather when you call it. > > For example, the 1st prime generation might happen just after > 1st boot when there're few sources of randomness on the device. > So while the 2nd prime may be much more random the probability > of the 1st one being the same as someone else's is high enough > to be a problem. (Apparently. He repeated:-) > > So there might be reasons to call this even if you're > confident of your key generation code, in case someone fed the > PRNG a crap seed. > > > S > >> >> It would be really nice if there was some way to audit RNGs >> algorithmically... >> >> >>>> As I have mentioned before though, public key is problematic in >>>> embedded systems. Most of the systems don't have the resources to do >>>> the job right and this will only get worse as time goes on because as >>>> a $1 processor gets more powerful a chip with a 6502 core gets cheaper >>>> and more are made. More 6502 type chips were made last year than in >>>> any previous year. >>>> >>>> >>>> So my view is that we have to get away from the idea that the endpoint >>>> has to do public key crypto. >>> >>> >>> >>> Well, that's one position but not necessarily the only one >>> with merit. >> >> >> Well certainly it is better that they do have a PKI stack but only if >> they do it right and that puts us way above what a PIC controller >> class chip with only a few Kb can be expected to do. >> >> Hence we need to have two tracks. Rather than telling people that they >> must do PKI on 16 bit chips, maybe have a different approach there. >> > --=20 Website: http://hallambaker.com/ From adam@cypherspace.org Fri Feb 17 15:11:09 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02EA11E80B0 for ; Fri, 17 Feb 2012 15:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETumOUPGt4WR for ; Fri, 17 Feb 2012 15:11:09 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id CE6DB11E80AE for ; Fri, 17 Feb 2012 15:11:08 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LZzCX-1SLmxb21qX-00m9oz; Fri, 17 Feb 2012 18:11:07 -0500 Received: by iagf6 with SMTP id f6so6017060iag.31 for ; Fri, 17 Feb 2012 15:11:06 -0800 (PST) Received-SPF: pass (google.com: domain of adam@cypherspace.org designates 10.50.203.6 as permitted sender) client-ip=10.50.203.6; Authentication-Results: mr.google.com; spf=pass (google.com: domain of adam@cypherspace.org designates 10.50.203.6 as permitted sender) smtp.mail=adam@cypherspace.org Received: from mr.google.com ([10.50.203.6]) by 10.50.203.6 with SMTP id km6mr14180853igc.25.1329520266169 (num_hops = 1); Fri, 17 Feb 2012 15:11:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.203.6 with SMTP id km6mr11219724igc.25.1329520266146; Fri, 17 Feb 2012 15:11:06 -0800 (PST) Received: by 10.42.244.68 with HTTP; Fri, 17 Feb 2012 15:11:06 -0800 (PST) In-Reply-To: <4F3D00D7.8020305@cs.tcd.ie> References: <4F3C04C9.7040601@cs.tcd.ie> <4F3D00D7.8020305@cs.tcd.ie> Date: Sat, 18 Feb 2012 00:11:06 +0100 Message-ID: From: Adam Back To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 X-Provags-ID: V02:K0:k+cv20fF/EvvvBUhBbSHsbRmzYCG9NPPuEJogDLZduJ +NfUm0xscZ3UCHS01Pro2zDcXjYAqgXR00RgrT0JSgYsqs9yWd CiXdAccCin5fTnxB0h1IIhedhIzZ7d6yT2rTneBdJh/9DBG9uG NmpD8DyStOcDafGBUq/VAgU6/DN9DQm67buszyvqnVGw0E96b6 ZyiR0W+lOkUZn5EF7MHPMrjE5J2jU/uLoLkDem/599HNcak9Zx KCNoCRGEmVEatVvAgvys/ti6ZIOxxO/9FcZaOXV7aU7xZk4PHv mr6qJ4l4B0TZjbJHCdELCt+KT2M7tijDVdwK+JHD92w43H6ToI BxeiMuD5lT9FiU0Ei6I23dQTtxQ01hVpe37jICeRdUB6/bwVOS h3f/yaHQ8LZoT+2skLtCm8joZDgqxjIedsF84Dj6sKizm2W1+v 90kv0 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 23:11:10 -0000 I dont think this is going to be very robust because the fact that the entropy seeding is so bad that some implementations are generating literally the same p value (but seemingly different q values) I would think you could view the fact that this can be detected and efficiently exploited via batch GCD as an indication of an even bigger problem. Namely if the seeding is that bad you could outright compute all possible values of p even for cases where p was not shared, by running through the evidently small by cryptographic standards number of possible PRNG states... Then you might be looking at more than 1% or whatever the number is that literally collide in specific p value. Assuming p is more vulnerable than q, you could then use the same batch GCD to test. Adam On 16 February 2012 14:12, Stephen Farrell wrote: > > Dunno if anyone else thinks this might be interesting > but I do:-) > > So I sketched out an initial idea for how it might fit > in here. [1] > > Comments welcome. > > S. > > [1] http://www.ietf.org/id/draft-farrell-kc-00.txt > > > On 02/15/2012 07:17 PM, Stephen Farrell wrote: >> >> >> Hiya, >> >> I guess the recent publications about common factors [1,2] >> are something else that this group might want to consider. >> >> I wonder if an rsa modulus checker protocol might help or >> something. Not sure if that's something that could be run >> quickly enough though, other than for the straight >> duplicates or dumbass things with small factors you should >> spot yourself. Anyone know? >> >> Or maybe you could register your public key and get a >> nonce, then come back periodically to see if any problems >> have been detected for your key. >> >> And yes, better prngs are needed, but there'll probably >> always be bad ones out there. >> >> S. >> >> [1] http://eprint.iacr.org/2012/064 >> [2] >> >> http://it.slashdot.org/story/12/02/15/1540212/factorable-keys-twice-as-many-but-half-as-bad >> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey From nico@cryptonector.com Fri Feb 17 15:11:20 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D291F11E80A5 for ; Fri, 17 Feb 2012 15:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBPdu4Y0eDwp for ; Fri, 17 Feb 2012 15:11:19 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1837F11E80AE for ; Fri, 17 Feb 2012 15:11:19 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id C6252594062 for ; Fri, 17 Feb 2012 15:11:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=puaYRaxMgOW0U6ZPN9RjR lh1g6tLji3tKY/JLK8Bcxu6Ezp6obJB/jM61XWNTgCWyyb6LClpnoigtyrXhGP7x ndICI5Je3+IXpNTRCnMoBRzYaRn1LP0BJDdQfSJvdAoWNnMDFBjRbWKa49YO028x A1lcYhenLNUmBo24wsFRSA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=XNLhPwHO4+g967wxhdg+ iogcvx0=; b=tJr96vbObcjuF94mWGBx80frlV50THmMbWTY17qoGTsiRKBltfE1 TC/Q013dvWKHCT5qiwohPycYQvYTrsedl4iQIpeqfZGIZtD7Od8Kl21Tjo1y/SW5 rAvGjZl1xoByPxgxujJKTUZ/ixNvX4pVSw3uY0gyAUcwug0mKbezV+4= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id ADEE9594061 for ; Fri, 17 Feb 2012 15:11:16 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so4416242pbc.31 for ; Fri, 17 Feb 2012 15:11:16 -0800 (PST) Received-SPF: pass (google.com: domain of nico@cryptonector.com designates 10.68.208.228 as permitted sender) client-ip=10.68.208.228; Authentication-Results: mr.google.com; spf=pass (google.com: domain of nico@cryptonector.com designates 10.68.208.228 as permitted sender) smtp.mail=nico@cryptonector.com Received: from mr.google.com ([10.68.208.228]) by 10.68.208.228 with SMTP id mh4mr35708399pbc.13.1329520276269 (num_hops = 1); Fri, 17 Feb 2012 15:11:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.208.228 with SMTP id mh4mr28828153pbc.13.1329520276250; Fri, 17 Feb 2012 15:11:16 -0800 (PST) Received: by 10.68.136.4 with HTTP; Fri, 17 Feb 2012 15:11:16 -0800 (PST) In-Reply-To: References: <4F3C04C9.7040601@cs.tcd.ie> <4F3D00D7.8020305@cs.tcd.ie> <4F3D0F0C.6010707@cs.tcd.ie> <4F3D12C4.3060901@cs.tcd.ie> Date: Fri, 17 Feb 2012 17:11:16 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: "therightkey@ietf.org" , Stephen Farrell Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 23:11:20 -0000 On Fri, Feb 17, 2012 at 4:51 PM, Phillip Hallam-Baker wrote: > 1) Random seed installed during manufacture > 2) Random capture from embedded RNG source / environmental capture > 3) Random caputure from UI > 4) Obtain random data from the network > >[...] > 1) Is actually not as bad as might be imagined, you trust the > manufacturer not to backdoor your crypto so having them give you a > seed is not terrible. Right. There's nothing wrong with this as a fallback. Also, we assume a clock or stable storage for a counter so as to avoid starting with the same seed every time. > 2) Is ideal but adds to hardware cost. Unless that is someone can work > out a cheap way to get random data into a D/A port or other I/O pin. A floating D/A input will do. Also, CPUs can implement an RNG relatively cheaply. Sun did it in UltraSPARC CPUs, and Intel does it now in theirs. As with all other things electronic is just a matter of getting it into one massively manufactured chip/chipset and then it will quickly get cheaper. (Smartphones, for example, are chuck-ful of inputs suitable for entropy gathering, and have modern CPUs. Even non-smartphone phones have lots of suitable inputs. You have to reach for devices like keyfobs to find devices where it'd be expensive to retrofit an RNG.) > 4) Is clearly sub optimal since the service knows the data sent. (4) is not so bad if you also have (1), because a) the vendor doesn't know the entropy obtained in (4) and the service in (4) doesn't know the vendor seed, thus if the device combines both then the vendor and service have to collude in order to recover the device's state. > How about this for a better protocol approach? > > Client generates random seeds. S1, S2 > Client sends Trunc(H(S1)) to the service > Service says 'hey I have seen that before' or 'nope it is new' + returns S3 > > Client generates new seed from H(S1 + S2 + S3 +c) > Where c is a counter that is incremented for each call for more random bits. Sure. And if you have RSA keys for the service and the client then you can authenticate the service and encrypt the entropy (so eavesdroppers can't see it). > Advantages: > > 1) The checking protocol is tied into the PRNG algorithm so that it is > really hard for the programmer to balls it up. If there are small enough perturbations in the seeding of the PRNG then eventually there will be enough devices with colliding state that will be detected. Yes, this is good. > 2) Only part of the ergodicity is checked, the protocol checks to see > that there are at least 128 bits worth of random data in the output. > > Cons: > > 1) Requires twice the amount of randomness to do the job right. Not necessarily. We should be willing to settle for computational entropy in many cases (i.e., it should be hard to recover the device's PRNG state from Trunc(H(S1)). > Also, this looks to me to be the sort of thing that you would want to > be a part of some form of device enrollment protocol. Yes. And if there's enough UI then the user can be asked to confirm that the public key of the RNG service is correct -- SSH-like, but since there will be few such services in any one org, it will generally be recognizable. Nico -- From stephen.farrell@cs.tcd.ie Fri Feb 17 15:23:37 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9356111E80A5 for ; Fri, 17 Feb 2012 15:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ws69LkQIIgEI for ; Fri, 17 Feb 2012 15:23:36 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 7145711E809F for ; Fri, 17 Feb 2012 15:23:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 92FCE171D0C; Fri, 17 Feb 2012 23:23:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1329521013; bh=PoiRKEBEJAm3DU 4h89i3yZFobkaN26+GbG1idmPmB5g=; b=KnTwQyF7qyEHJp+dxfpqiSEIvVlkfn J14kd4SwK1lCzqY8XMX0CLN1XdAU3l+Yy5mMSmyz9lR1YjHpFKfMQbHKanNkb7uv /CUwtRhHUdovnMcU4txYShvO2DbwtEagob/08pf2sZ1IUgBTobVkRpnd7Q+jFqC8 SEVA8xEqNygs99kbwh2xQ7UDb7QPGHmiXnA6cgCmj52eMrj3AtD/uEIXCQ+C+0ZB T8r+lhZw9Tq/wBM3Y/df+U8JC3X8riGzZoxTLXGLgLm2PjTMUxBzIR8Xa2jxAzp7 k/jXfaq7CoBWdYINr8UDP+uR2ZYsjSrqhqASVx13h4DclhzRFlNmgKdw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id k6bnT26TxOV4; Fri, 17 Feb 2012 23:23:33 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.41.9.27]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6105D171C71; Fri, 17 Feb 2012 23:23:33 +0000 (GMT) Message-ID: <4F3EE16A.3040507@cs.tcd.ie> Date: Fri, 17 Feb 2012 23:23:22 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Adam Back References: <4F3C04C9.7040601@cs.tcd.ie> <4F3D00D7.8020305@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 23:23:37 -0000 Hiya, On 02/17/2012 11:11 PM, Adam Back wrote: > I dont think this is going to be very robust because the fact that the > entropy seeding is so bad that some implementations are generating > literally the same p value (but seemingly different q values) I would > think you could view the fact that this can be > detected and efficiently exploited via batch GCD as an indication of an even > bigger problem. > > Namely if the seeding is that bad you could outright compute all possible > values of p even for cases where p was not shared, by running through the > evidently small by cryptographic standards number of possible PRNG states... > > Then you might be looking at more than 1% or whatever the number is that > literally collide in specific p value. Assuming p is more vulnerable than > q, you could then use the same batch GCD to test. Sure. But wouldn't this protocol still help then? Assuming that protocol clients don't ignore the known-bad answers, they'd hopefully iterate until they get a not-known-bad key one way or another. I think so, but maybe you're seeing something I'm not. Something not that clear in the -00 is that the responder here can supply random bits as a side effect of answering the query. (The -01 will make this clearer when its ready.) S. > > Adam > > On 16 February 2012 14:12, Stephen Farrell wrote: >> >> Dunno if anyone else thinks this might be interesting >> but I do:-) >> >> So I sketched out an initial idea for how it might fit >> in here. [1] >> >> Comments welcome. >> >> S. >> >> [1] http://www.ietf.org/id/draft-farrell-kc-00.txt >> >> >> On 02/15/2012 07:17 PM, Stephen Farrell wrote: >>> >>> >>> Hiya, >>> >>> I guess the recent publications about common factors [1,2] >>> are something else that this group might want to consider. >>> >>> I wonder if an rsa modulus checker protocol might help or >>> something. Not sure if that's something that could be run >>> quickly enough though, other than for the straight >>> duplicates or dumbass things with small factors you should >>> spot yourself. Anyone know? >>> >>> Or maybe you could register your public key and get a >>> nonce, then come back periodically to see if any problems >>> have been detected for your key. >>> >>> And yes, better prngs are needed, but there'll probably >>> always be bad ones out there. >>> >>> S. >>> >>> [1] http://eprint.iacr.org/2012/064 >>> [2] >>> >>> http://it.slashdot.org/story/12/02/15/1540212/factorable-keys-twice-as-many-but-half-as-bad >>> >>> _______________________________________________ >>> therightkey mailing list >>> therightkey@ietf.org >>> https://www.ietf.org/mailman/listinfo/therightkey >>> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From aerowolf@gmail.com Fri Feb 17 15:27:22 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D232C11E80A5 for ; Fri, 17 Feb 2012 15:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyMHjbI58rV0 for ; Fri, 17 Feb 2012 15:27:21 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B19C711E809F for ; Fri, 17 Feb 2012 15:27:21 -0800 (PST) Received: by dakl33 with SMTP id l33so3929488dak.31 for ; Fri, 17 Feb 2012 15:27:21 -0800 (PST) Received-SPF: pass (google.com: domain of aerowolf@gmail.com designates 10.68.138.167 as permitted sender) client-ip=10.68.138.167; Authentication-Results: mr.google.com; spf=pass (google.com: domain of aerowolf@gmail.com designates 10.68.138.167 as permitted sender) smtp.mail=aerowolf@gmail.com; dkim=pass header.i=aerowolf@gmail.com Received: from mr.google.com ([10.68.138.167]) by 10.68.138.167 with SMTP id qr7mr36557963pbb.0.1329521241608 (num_hops = 1); Fri, 17 Feb 2012 15:27:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:date:message-id:subject:in-reply-to:references :mime-version:content-type; bh=Sk1Zb2H1JHxTBwGgow16vMYQONavcQ3e2SYi4hEU3tI=; b=MBs0knLrD4w21u+Zam8fteHgbZDTXiYzXXHoteTzwNWWSkcI1vpWiz9bjtrUKH8AhE vORd3c09X6Jceq1dsp9T8oSv2VtxlOkp1xt+VfN0s9VwQTnn9PjQixCEHuPV4ROjKrKE bUmToW0/gH5X6KjPXUbW+f/HASu3JsBr4tIP0= Received: by 10.68.138.167 with SMTP id qr7mr29589788pbb.0.1329521241543; Fri, 17 Feb 2012 15:27:21 -0800 (PST) Received: from penango (c-67-188-178-93.hsd1.ca.comcast.net. [67.188.178.93]) by mx.google.com with ESMTPS id f10sm6307330pbn.58.2012.02.17.15.27.16 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 15:27:18 -0800 (PST) From: "Kyle Hamilton" To: "Nico Williams" Date: Fri, 17 Feb 2012 15:27:22 -0800 (Pacific Standard Time) Message-ID: In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary=gmsm1.9.5eqgyrumc383trqtx7pki2 Cc: "therightkey@ietf.org" , Peter Gutmann , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 23:27:22 -0000 This is an S/MIME signed message generated with Penango. --gmsm1.9.5eqgyrumc383trqtx7pki2 Content-Transfer-Encoding: base64 Content-Type: text/plain; format=flowed; charset=iso-8859-1 DQpPbiBXZWQsIEZlYiA4LCAyMDEyIGF0IDk6MzUgUE0sIE5pY28gV2lsbGlhbXMgPG5pY29AY3J5 cHRvbmVjdG9yLmNvbT4gd3JvdGU6DQo+IEUtbWFpbCBpcyBub3QgYW4gb25saW5lIHByb3RvY29s IGJldHdlZW4gdHdvIE1VQXMuIKBXaGVuIHlvdSBzZW5kIGFuDQo+IGUtbWFpbCB5b3VyIE1VQSBp cyBub3QgdGFsa2luZyBkaXJlY3RseSB0byB0aGUgcmVjaXBpZW50J3MgTVVBLCBhbmQNCj4gdGhl cmUgYXJlIG5vIGF1dG9tYXRlZCByZXBsaWVzIGV4Y2VwdCBmb3IgdmFjYXRpb24gcmVwbGllcy4N Cg0KVGhhdCBsYXN0IGFzc2VydGlvbiBpcyBkZW1vbnN0cmFibHkgZmFsc2UuICBBbW9uZyBvdGhl ciB0aGluZ3MsIHRoZXJlJ3MgdGhlICJyZXR1cm4gcmVjZWlwdCByZXF1ZXN0ZWQiIHByb2Nlc3Nv ci4gIFRoZXJlJ3MgdGhlICJtYWlsaW5nIGxpc3QgZGlzdHJpYnV0aW9uIGF1dG9yZXNwb25kZXIi LiAgVGhlcmUgaXMgd2hhdCBJJ20gZGV2ZWxvcGluZywgd2hpY2ggaXMgZXhhY3RseSB3aGF0IEkn bSB0YWxraW5nIGFib3V0Lg0KDQpFbWFpbCBhY2NlcHRhbmNlIGJ5IGFuIE1UQSBkb2VzIG5vdCBo YXZlIGEgZGl2aW5lIHJpZ2h0IHRvIGEgcmVwbHkuICBCdXQgaWYgaXQgZG9lcyBtZXJpdCBvbmUs IHdvdWxkbid0IGl0IGJlIG5pY2UgZm9yIHRoZSByZW1vdGUgdG8gYmUgYWJsZSB0byBvcHBvcnR1 bmlzdGljYWxseSBlbmNyeXB0IGl0IHdpdGgga25vd2xlZGdlIG9mIG91ciBzZWN1cml0eSBjYXBh Y2l0aWVzPyAgUmVtZW1iZXIsIHRoZSBvbmx5IHRoaW5nIHRoYXQgd2UgY2FuIHVsdGltYXRlbHkg cmVseSBvbiBpcyB0aGF0IGEgcHVibGljIGtleSBpZGVudGlmaWVzIGl0cyBvd24gYW5kIG9ubHkg aXRzIG93biBwcml2YXRlIGtleS4gIFdlIGNhbiB1c2UgdGhhdCB0byBvdXIgYWR2YW50YWdlLCBp ZiB3ZSBzdG9wIHdvcnJ5aW5nIHNvIG11Y2ggYWJvdXQgTWl0TSBhdCB0aGUgY3J5cHRvZ3JhcGh5 IGxheWVyIGFuZCBpbnN0ZWFkIHByZXNlbnQgdGhlICJ5b3UgbWlnaHQgbm90IGJlIHNwZWFraW5n IG9ubHkgdG8gd2hvIHlvdSB0aGluayB5b3UncmUgc3BlYWtpbmcgdG8sIHNvbWVvbmUgZWxzZSBt aWdodCBiZSBsaXN0ZW5pbmcgaW4sIHNvIGRvbid0IHNheSBhbnl0aGluZyB0aGF0IHlvdSB3YW50 IHRvIGtlZXAgcHJpdmF0ZSIgTWl0TSBwb3NzaWJpbGl0eSBlbHNld2hlcmUgaW4gdGhlIFVJLg0K DQo+IFRodXMgaW4gYSBjb2xkLWNhbGwgZS1tYWlsIHNlbmQgeW91IGhhdmUgbm8ga25vd2xlZGdl IGFib3V0IHRoZQ0KPiByZWNpcGllbnQncyBNVUEncyBjYXBhYmlsaXRpZXMuIKBZb3UgY2FuIG9u bHkgc2lnbiB5b3VyIGUtbWFpbCBhbmQNCj4gaG9wZSB0aGF0IHRoZSByZWNpcGllbnQgY2FuIHZh bGlkYXRlIHRoZSBzaWduYXR1cmUuDQoNCkEgY29sZC1jYWxsIGVtYWlsIGlzIGEgc3BlY2lhbCBj YXNlLiAgVGhlIGluaXRpYWwgcmVwbHkgaXNuJ3QgYSBjb2xkLWNhbGwgZW1haWwuIG5vciBpcyBh bnkgcmVwbHkgYWZ0ZXIgdGhhdC4gIE5laXRoZXIgaXMgYW55IGZ1cnRoZXIgY29tbXVuaWNhdGlv biB3aXRoIHRoYXQgZW5kcG9pbnQuDQoNCkl0IGlzIGFic3VyZCB0aGF0IHdlJ3JlIGxldHRpbmcg dGhlIHNwZWNpYWwgY2FzZSBiZWNvbWUgdGhlIGVuZW15IG9mIHRoZSBnb29kLiAgIldlIGFzc3Vt ZSB0aGF0IGJlY2F1c2UgaXQncyBub3QgcHJlc2VudGx5IHBvc3NpYmxlIHRvIHF1ZXJ5IHB1Ymxp YyByZWdpc3RyaWVzIGZvciBlbWFpbCBrZXlzLCB0aGUgZW50aXJlIG1vZGVsIGFuZCBjb25jZXB0 IGlzIGNyYXAuIiAgVGhpcyBpcyBhbm90aGVyIGluc3RhbmNlIG9mIHRoZSBiaW5hcnkgImNvbXBs ZXRlbHkgdXR0ZXJseSBibGluZGx5IGNvcnJlY3QiIG9yICJpdCdzIG5vdCB3b3J0aCB0aGUgYml0 cyBpdCdzIGVuY29kZWQgaW4iLCBhbmQgaXQncyBhcyBoYXJtZnVsIGhlcmUgYXMgaXQgaXMgaW4g dGhlIGJyb3dzZXIgc2VjdXJpdHkgbW9kZWwuDQoNCldlIG11c3QgZml4IHRoZSBzZWN1cml0eSBt b2RlbCBoZXJlLCBub3QgcHVzaCB0aGUgYnVyZGVuIG9udG8gYXBwbGljYXRpb24gZGVzaWduZXJz IHdobyBoYXZlIG5laXRoZXIgZ3VpZGFuY2Ugbm9yIGV4cGVydGlzZSBpbiB0aGUgZmllbGQuDQoN Cj4gSWYgeW91IGtub3cgdGhlIHJlY2lwaWVudCdzIHB1YmxpYyBrZXkgYW5kIGNhbiBkZXJpdmUg c29tZSBrbm93bGVkZ2UNCj4gYWJvdXQgdGhlIHJlY2lwaWVudCdzIE1VQSdzIGNhcGFiaWxpdGll cyBmcm9tIHRoYXQgcHVibGljIGtleSBhbmQNCj4gc3Vycm91bmRpbmcgbWF0ZXJpYWwsIHN1Y2gg YXMgYSBjZXJ0aWZpY2F0ZSBvciBvdGhlciBtZXRhZGF0YSwgdGhlbg0KPiB5b3UgY2FuIHNlbmQg c2lnbmVkIGFuZCBlbmNyeXB0ZWQgZS1tYWlsIHRvIHRoZW0uDQoNClRoZXJlIGlzIG1ldGFkYXRh IGFzc29jaWF0ZWQgd2l0aCBldmVyeSBlbWFpbC4gIEl0IGV4aXN0cyBpbiB0aGUgZm9ybSBvZiBo ZWFkZXJzLiAgVGhlc2UgaGVhZGVycyBpZGVudGlmeSwgYW1vbmcgb3RoZXIgdGhpbmdzLCB0aGUg TVVBIHRoZSBzZW5kZXIgaXMgdXNpbmcuICBUaGVyZSdzIG5vIHJlYXNvbiB0aGlzIGNhbid0IGJl IGV4dGVuZGVkLiAgKEluIGZhY3QsIGV4dGVuZGluZyBpdCBpcyBlbmNvdXJhZ2VkISkNCg0KSWYg dGhlIHNlbmRpbmcgTVVBIGluY2x1ZGVzIChmb3IgZXhhbXBsZSkgYW4gRUMgcHVibGljIGtleSBh bmQgbm90ZXMgdGhhdCBpdCBzdXBwb3J0cyBFQ0RIIHdpdGggU2hhMTI4IG9yIFNoYTI1NiBrZXkg ZGVyaXZhdGlvbiBhbmQgQWVzMTI4IG9yIEFlczI1NiwgdGhlcmUgaXMgbm8gY2VydGlmaWNhdGUg aW52b2x2ZWQgc28gdGhlcmUncyBubyBmZWFyLiAgVGhlIHJlY2lwaWVudCBNVUEgY2FuIHNlZSB0 aGF0IHB1YmxpYyBrZXkgaW4gdGhlIGhlYWRlciwgYW5kIGl0IGNhbiBnZW5lcmF0ZSBpdHMgb3du IEVDIHB1YmxpYyBrZXkgdG8gaW5jbHVkZSBpbiB0aGUgaGVhZGVyIG9mIHRoZSByZXBseSAtLSB3 aGljaCBoYXMgYmVlbiBlbmNyeXB0ZWQgd2l0aCB0aGUgRUNESC1kZXJpdmVkIHNoYXJlZCB2YWx1 ZSBhcyB0aGUga2V5Lg0KDQpXZSBtdXN0IHBlcm1pdCB0aGlzIGtpbmQgb2Ygb3Bwb3J0dW5pc3Rp YywgdW5hdXRoZW50aWNhdGVkIGVuY3J5cHRpb24sIGJlY2F1c2UgZW1haWwgaXMgZmFyIHRvbyBp bXBvcnRhbnQgdG8gbGVhdmUgcGxhaW50ZXh0LiAgV2UgbXVzdCBhY2NlcHQgdGhhdCBBbGljZSBo YXMgYWJzb2x1dGUgcmlnaHQgdG8gcHV0IHdoYXRldmVyIHNoZSB3YW50cyBpbiBoZXIgbWVzc2Fn ZXMsIGFuZCBzaGUgY2FuIGVuZ2FnZSBpbiBhbnkgYWN0aXZpdHkgc2hlIHdhbnRzIHRvIGRvIHRv IGZpZ3VyZSBvdXQgd2hhdCBpdCdzIGdvaW5nIHRvIGJlLiAgV2UgbXVzdCBhY2NlcHQgdGhhdCBC b2IgaGFzIHRoZSBhYnNvbHV0ZSByaWdodCB0byBkbyB3aGF0ZXZlciBoZSB3YW50cyB3aXRoIGFu eSBtZXNzYWdlIGhlIHJlY2VpdmVzLCBubyBtYXR0ZXIgaXRzIGNvbnRlbnQuICAgV2UgbXVzdCBw bGFuIGZvciB3aGVuIEJvYiBkb2Vzbid0IHdhbnQgdG8gYWJpZGUgYnkgQWxpY2UncyBzZWN1cml0 eSBwb2xpY3ksIGJ5IG1ha2luZyB0aGUgc3lzdGVtIGRlcGVuZCBvbiBjb3B5cmlnaHQgZXhlcmNp c2UgKHdoaWNoIGluY2x1ZGVzIHRoZSBleGNsdXNpdmUgb3duZXJzaGlwIG9mIHRoZSByaWdodCB0 byBkZXJpdmUgYSBzaGFyZWQga2V5IGZyb20gYSBwdWJsaWMga2V5KS4gIFdlIG11c3QgcGxhbiBm b3Igd2hlbiBBbGljZSBzZW5kcyBzb21ldGhpbmcgdG8gQm9iIHRoYXQgYnJlYWtzIG91ciBuYXJy b3ctbWluZGVkIGludGVycHJldGF0aW9uIG9mIHRoZSBydWxlcywgYW5kIHByZXNlbnQgaXQgYXMg c29tZXRoaW5nIG90aGVyIHRoYW4gZnVsbC1zdG9wICJ0aGlzIGlzbid0IHNvbWV0aGluZyBJIChz b2Z0d2FyZSkgcmVjb2duaXplLCBzbyBJIG5vdCBvbmx5IHdvbid0IGxldCB5b3UgZG8gaXQsIEkn bGwgc2NhcmUgeW91IGF3YXkgZnJvbSBpdC4iICBXZSBtdXN0IHBsYW4gZm9yIHdoZW4gQm9iIHNl bmRzIHNvbWV0aGluZyB3aXRoIGEgY2xpY2t3cmFwIGxpY2Vuc2UgdGhhdCBBbGljZSBkb2Vzbid0 IHdhbnQgdG8gYWNjZXB0Lg0KDQpJZiB3ZSBkbyBpdCByaWdodCwgd2UgZW5mb3JjZSB0aGF0IHRo ZSBkZXJpdmF0aW9uIG9mIHRoZSBzaGFyZWQga2V5IGlzIHN1YmplY3QgYm90aCB0byBBbGljZSdz IHBvbGljeSAoYnkgZGVyaXZpbmcgdGhlIHNoYXJlZCBrZXkgdG8gc2VuZCB3aXRoKSBhbmQgQm9i J3Mgb3RoZXJ3aXNlLXVuaWxhdGVyYWwgaW1wb3NpdGlvbiBvZiBwb2xpY3kuICBUaGlzIG1ha2Vz IHRoZSBwYXJ0aWNpcGFudHMgcGVlcnMgaW4gdGhlIGNvbnZlcnNhdGlvbiwgbm90IG9uZSBtYXN0 ZXIgYW5kIG9uZSBzbGF2ZS4NCg0KIKBUaGUgcmVxdWlyZWQNCj4gbWV0YWRhdGEgLXRoZSByZWNp cGllbnQncyBNVUEncyBjYXBhYmlsaXRpZXMtIGFyZSBmb3VuZCB3aGVyZSB0aGUNCj4gcmVjaXBp ZW50J3MgcHVibGljIGtleSBpcyBmb3VuZC4goFRoYXQgbWV0YWRhdGEgaGFzIHRvIGJlIHNvbWV3 aGVyZSwNCj4gYnV0IGUtbWFpbCBoZWFkZXJzIGlzbid0IHRoYXQgc29tZXdoZXJlLg0KDQpOb3Qg cmlnaHQgbm93LiAgSSBiZWxpZXZlIGl0IHNob3VsZCBiZSwgYmVjYXVzZS4uLg0KDQogoFRoaXMg bGltaXRzIHlvdXIgYW5kIHlvdXINCj4gY29ycmVzcG9uZGVudHMnIGFiaWxpdHkgdG8gc3dpdGNo IHRvIG90aGVyIE1VQXM6IHRoZXknZCBiZXR0ZXIgc3VwcG9ydA0KPiB0aGUgY2FwYWJpbGl0aWVz IHRoYXQgeW91J3ZlIGFkdmVydGlzZWQgd2l0aCB5b3VyIGtleXMuDQoNCi4uLm1vcmUgY29ycmVj dGx5LCB0aGV5J2QgYmV0dGVyIHN1cHBvcnQgdGhlIGNhcGFiaWxpdGllcyB0aGF0IG15IENBIGhh cyBhZHZlcnRpc2VkIHdpdGggbXkga2V5LCBhbmQgSSdkIGJldHRlciBub3QgY2hhbmdlIG15IGNs aWVudCB0byBzb21ldGhpbmcgd2l0aCBkaWZmZXJlbnQgY2FwYWJpbGl0aWVzIG9yIGxvc2UgdGhl IHByaXZhdGUga2V5ICh3aGljaCwgaW4ga2VlcGluZyB3aXRoIHNlY3VyaXR5IGV4dHJlbWlzbSwg SSBoYXZlIGNyZWF0ZWQgaW4gYSBwaWVjZSBvZiBoYXJkd2FyZSBzdWNoIHRoYXQgSSBjYW4ndCBl eHBvcnQgaXQgLS0gbWVhbmluZyB0aGF0IGFzIHNvb24gYXMgdGhlIGhhcmR3YXJlIGRpZXMsIEkn dmUgbG9zdCB0aGUga2V5KS4gIElmIEkgY2hhbmdlIGNsaWVudHMsIG9yIGhlYXZlbiBmb3JiaWQg aGF2ZSBtdWx0aXBsZSBjbGllbnRzIHdpdGggZGlmZmVyZW50IGNhcGFiaWxpdGllcywgSSByZXF1 aXJlIHRoZSBjb29wZXJhdGlvbiBvZiBhbiBleHRlcm5hbCBlbnRpdHksIHdoaWNoIGlzIGEgY29t bWVyY2lhbCBlbnRlcnByaXNlIGNoYXJnaW5nIG1lIGZvciB0aGF0IGNvb3BlcmF0aW9uLg0KDQpU aGUgY29tbW9uIGluc2lzdGVuY2Ugb24gIm11c3QgYmUgYXV0aG9yaXRhdGl2ZSBDQSIgb3BlcmF0 ZXMgaW4gdGhlIHJlYWwgd29ybGQgYXMgbm90aGluZyBtb3JlIHRoYW4gYSByYWlscm9hZCBpbnRv IGEgcmFja2V0LiAgVGhpcyBpcyB3aHkgYSBoZWFkZXIgaXMgbmVjZXNzYXJ5LiAgSXQgaXMgdGhl IGxlYXN0IG1vdGlvbiB3aGljaCBtdXN0IGJlIG1hZGUgdG8gZW5hYmxlIG9wcG9ydHVuaXN0aWMg ZW5jcnlwdGlvbi4gIChUaGUgYWx0ZXJuYXRpdmUgaXMgYWxsb3dpbmcgc2VsZi1zaWduZWQgUy9N SU1FIGNlcnRpZmljYXRlcywgdGhhdCB0aGUgY2xpZW50IHNvZnR3YXJlIGNyZWF0ZXMgaXRzZWxm LiAgSSBkb24ndCBrbm93IHRoYXQgcGVvcGxlIHdvdWxkIHJlYWxseSBsaWtlIHRvIGFjY2VwdCBz ZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZXMgd2l0aG91dCBhIHdheSB0byBsZXZlcmFnZSB0aGUgZXhp c3RpbmcgQ0EgaW5mcmFzdHJ1Y3R1cmUgYW5kIGl0cyBhdXRob3JpdGF0aXZlIGlkZW50aXR5IGFz c2VydGlvbnMuKSAgDQoNCj4gU3VyZSwgd2UgY291bGQgYnVpbGQgYSBUTFMtbGlrZSBwcm90b2Nv bCBvdXQgb2YgZS1tYWlsLCBpZiBNVUFzIGtuZXcNCj4gaG93IHRvIHNwZWFrIHRvIGVhY2ggb3Ro ZXIgdGhlIG1haWwgbmV0d29yay4NCg0KVGhleSBkby4gIFRoZSBwYWNrZXQgaXMgY2FsbGVkIGEg bWVzc2FnZSwgdGhlIHRyYW5zcG9ydCBpcyBjYWxsZWQgInRoZSBNVEEgbmV0d29yayIuICBUaGUg cGFja2V0IGFycml2ZXMgaW4gc3Vic3RhbnRpYWxseSB1bmNoYW5nZWQgZm9ybSBhdCB0aGUgZGVz dGluYXRpb24gdmlhIGEgcmVjZXB0aW9uIHByb3RvY29sIHN1Y2ggYXMgSU1BUCBvciBQT1AzLg0K DQogoFlvdSdkIHNheSB5b3Ugd2FudCB0bw0KPiBzZW5kIGUtbWFpbCB0byBKb2VAc29tZS1kb21h aW4uZXhhbXBsZSBhbmQgeW91ciBNVUEgY291bGQgc2VuZCBhDQo+IHNwZWNpYWxseSBjcmFmdGVk IGUtbWFpbCB0aGF0IEpvZSdzIE1VQSB1bmRlcnN0YW5kcyBhcyBhIENsaWVudEhlbGxvDQo+IChh bmQgd2hpY2ggSm9lIHdvdWxkbid0IHNlZSwgYXMgaXQgd291bGQgZG8gSm9lIG5vIGdvb2QgdG8g c2VlIGl0KSwNCj4gcmVzcG9uZGluZyB3aXRoIFNlcnZlckhlbGxvIGFuZCBzbyBvbiwgYW5kIHRo ZW4geW91IGhhdmUgYSBzZXNzaW9uIGtleQ0KPiB0aGF0IHlvdSBjYW4gdXNlIHRvIHNlbmQgZW5j cnlwdGVkIG1haWwgdG8gSm9lLg0KDQpIYXZlIHlvdSBub3QgaGVhcmQgb2YgRGlmZmllLUhlbGxt YW4/ICBPciBFbGxpcHRpY2FsIEN1cnZlIERpZmZpZS1IZWxsbWFuPyAgVGhpcyBpcyBhIG1hdGhl bWF0aWNhbCB0cmFuc2Zvcm1hdGlvbiB3aGljaCBhbGxvd3MgdHdvIGluZGVwZW5kZW50IHByaXZh dGUga2V5IGhvbGRlcnMgdG8gYXJyaXZlIGF0IHRoZSBzYW1lIHZhbHVlIHVzaW5nIG9uZSdzIG93 biBwcml2YXRlIGtleSBhbmQgdGhlIG90aGVyJ3MgcHVibGljIGtleSwgYmFzZWQgc29sZWx5IHVw b24gb25lIGV4Y2hhbmdlIG9mIHB1YmxpYyBrZXkgbWF0ZXJpYWwuICBUaGVyZSdzIG5vIG5lZWQs IHJlYXNvbiwgb3IgZGVzaXJlIGZvciBhIGZ1bGwgQ2xpZW50SGVsbG8gVExTIG5lZ290aWF0aW9u LCBhbmQgZm9jdXNpbmcgb24gdGhlIGhhbmRzaGFrZSB0byB0aGUgZXhjbHVzaW9uIG9mIHdoYXQg dGhlIHRlY2hub2xvZ3kgYWN0dWFsbHkgcGVybWl0cyBpcyBhbiBhc3RvdW5kaW5nbHkgdW5pbnRl bGxpZ2VudCBpZGVhLiAgVGhpcyBpcyBhbm90aGVyIHByb2JsZW0sIHBlb3BsZSBpbnZvbHZlZCBp biB0aGUgcHJvY2Vzc2VzIHdobyBkb24ndCBrbm93IHdoYXQgdGhlIGNyeXB0b2dyYXBoeSBhY3R1 YWxseSBhbGxvd3MgZm9yIHNvIHRoZXkgY2FuJ3QgY29tcHJlaGVuZCB3aGVuIHRoZWlyIHJ1bGVz IGFyZSBoYXJtZnVsLg0KDQogoEFuZCB0aGVuIHdlJ2QgbmVlZCB0bw0KPiBuZWdvdGlhdGUgY2lw aGVyIHN1aXRlcyBhbmQgc3VjaCBqdXN0IGxpa2UgVExTLiCgQnV0IHRoYXQncyBub3QgaG93DQo+ IGUtbWFpbCB3b3Jrcy4goFlvdSBzZW5kIGFuIGUtbWFpbCwgYW5kIGhvcGVmdWxseSBpdCBnZXRz IHRoZXJlLCBhbmQNCj4gdGhlcmUncyBubyBhdXRvbWF0aWMgcGluZy1wb25nIHVudGlsIGtleXMg YXJlIGVzdGFibGlzaGVkLCB0aGVyZSdzDQo+IG9ubHkgdGhhdCBvbmUgZS1tYWlsLg0KDQpXb3cu ICBGcm9tIHRoaXMgZGVzY3JpcHRpb24sIG9uZSB3b3VsZCB0aGluayB0aGF0IHRoZSByZWNpcGll bnQgTVVBIGRpZG4ndCBoYXZlIHRoZSBwb3dlciB0byBwYXJzZSBoZWFkZXJzLCBzZW5kIHZpYSBT TVRQLCBvciBrZWVwIHRyYWNrIG9mIHRoZSBwYXJhbWV0ZXJzIHRoYXQgd2VyZSBzZW50IHdpdGgg YW55IGdpdmVuIG1lc3NhZ2Ugb3IgZnJvbSBhbnkgZ2l2ZW4gc2VuZGVyLiAgT25lIHdvdWxkIGFs c28gdGhpbmsgdGhhdCBpdCB3YXMgaW1wb3NzaWJsZSBmb3IgYXV0b21hdGljIG1haWwgcHJvY2Vz c29ycyB0byBleGlzdCwgbGlrZSByZW1haWxpZXJzLg0KDQpZb3VyIHBvaW50IGlzIG1pc2FwcGxp ZWQsIGl0J3MgbXVjaCBtb3JlIHN1aXRlZCB0byBVc2VuZXQgdGhhbiBlbWFpbC4gIFVzZW5ldCBp bXBsaWVzICJJJ20gcG9zdGluZyBzb21ldGhpbmcgZm9yIGFueW9uZSB0byByZWFkIi4gIEVtYWls IGltcGxpZXMgIkknbSBzZW5kaW5nIGEgY29tbXVuaXF1ZSB0byBzb21lb25lIHdpdGggd2hvbSBJ IHdhbnQgdG8gZW5nYWdlIGluIGRpYWxvZ3VlLiIgIFRoZSBzcGVjaWFsIGNhc2Ugb2YgImNvbGQg Y2FsbCBlbWFpbCIgaXMgbXVjaCwgbXVjaCBsZXNzIGNvbW1vbiB0aGFuIHRoZSBjb21tb24gY2Fz ZSBvZiAibWFpbCB0byBhIGNvbGxlYWd1ZSBvciBzb21lb25lIHdpdGggYSBwcmUtZXhpc3Rpbmcg cmVsYXRpb25zaGlwIi4gIEdldHRpbmcgaHVuZyB1cCBvbiB0aGUgc3BlY2lhbCBjYXNlIGhhcyBw cmV2ZW50ZWQgc29sdXRpb25zIGZvciB0aGUgY29tbW9uIGNhc2UuDQoNCk91ciBqb2IgaXMgdG8g c3BlY2lmeSBpbnRlcm9wZXJhYmlsaXR5IHN0YW5kYXJkcywgbm90IHRvIGluZmxpY3Qgb3VyIHBl cnNvbmFsIGhvcml6b25zIG9uIHRoZSB1dGlsaXR5IG9mIHRoZSBzdGFuZGFyZHMgd2UgY29tZSB1 cCB3aXRoLiAgKFB1dCBhbm90aGVyIHdheTogSnVzdCBiZWNhdXNlIGEgc3RhbmRhcmRzIGRlc2ln bmVyIGNhbid0IGNvbXByZWhlbmQgd2h5IGEgY2xpZW50IGxlZ2l0aW1hdGVseSBhbmQgdmFsaWRs eSBuZWVkcyBhIHBhcnRpY3VsYXIgY2FwYWNpdHkgZG9lc24ndCBtZWFuIHRoYXQgdGhlIHN0YW5k YXJkcyBib2R5IGhhcyB0aGUgcmlnaHQgb3IgcmVzcG9uc2liaWxpdHkgdG8gcHJvaGliaXQgaXQg aW4gdGhlaXIgb3V0cHV0LikNCg0KU28uICBZb3Ugc2VuZCBhIHF1aWNrIHF1ZXJ5IHNpZ25lZCB3 aXRoIGEgdGhyb3dhd2F5IHVuY2VydGlmaWVkIGtleSB0byB0aGUgaW50ZW5kZWQgcmVtb3RlLCB2 aWEgU01UUC4gIFRoZSByZWNpcGllbnQgTVVBIHJlY2VpdmVzIHRoYXQgbWVzc2FnZSwgcGFyc2Vz IGl0LCBhbmQgdGhlbiBzZW5kcyAodmlhIFNNVFApIGEgc2VsZi1zaWduZWQga2V5IGVuY3J5cHRl ZCB0byB0aGUgcHVibGljIGtleSB5b3UgcXVlcmllZCB3aXRoLiAgVGhpcyBpcyBhY2NvbXBsaXNo ZWQgd2l0aCBpbmZvcm1hdGlvbiBpbiBhIGhlYWRlciB3aGljaCBNVUFzIGFscmVhZHkgcGFyc2Us IHN1Y2ggYXMgRnJvbTosIFJlcGxpZXMtVG86LCBhbmQgRXJyb3JzLVRvOiBoZWFkZXJzLg0KDQpJ ZiB3ZSBkbyBpdCByaWdodCwgd2UgZG9uJ3QgaGF2ZSB0byBkaXNjbG9zZSB0aGUgc2VuZGVyJ3Mg b3IgcmVjaXBpZW50J3MgaWRlbnRpdGllcywgZXZlbiB0byBlYWNoIG90aGVyIC0tIHdoaWxlIHN0 aWxsIG9idGFpbmluZyB0aGUgYmVuZWZpdHMgb2Ygc3Ryb25nIGF1dGhlbnRpY2F0aW9uIGFuZCBh Y2NvdW50YWJpbGl0eSBpbiB0aGUgbmV0d29yay4gIFJpZ2h0IG5vdywgaXQgcmVsaWVzIHVwb24g dGhlIGRpc2Nsb3N1cmUgb2YgZW1haWwgYWRkcmVzc2VzLiAgSSBoYXZlIGEgZGVzaWduIHdoaWNo IGRvZXNuJ3QgZXZlbiBuZWVkIHRoYXQuDQoNCj4gVGhhdCdzIHdoeSBTL01JTUUgYW5kIFBHUCB3 b3JrIHRoZSB3YXkgdGhleSBkby4NCg0KVGhhdCBoYW5ndXAgaXMgYWxzbyAob25lIG9mIHRoZSBy ZWFzb25zKSB3aHkgUy9NSU1FIGFuZCBQR1AgaGF2ZW4ndCBjYXVnaHQgb24uICAoRm9yIG1vcmUs IHNlZSBiZWxvdy4pDQoNClMvTUlNRSBhbmQgUEdQIHJhdGhlciBtaXNzZWQgbXVjaCBvZiB0aGUg cG9pbnQsIGJlY2F1c2UgZXZlcnlib2R5IGluIE9QR1AtV0cgYW5kIFBLSVgtV0cgaGF2ZSBiZWVu IHRvbyBodW5nIHVwIG9uIHdoYXQgb3RoZXIgcGVvcGxlIHNheSBpZGVudGl0aWVzIGFyZS4gIFRo YXQgaGFuZy11cCBoYXMgY2F1c2VkIHRoZXNlIHNlY3VyaXR5IHRlY2hub2xvZ2llcyB0byBiZSB1 bmFjY2VwdGFibHkgdXNlbGVzcyBpbiB0aGUgcmVhbCB3b3JsZC4gIFRoZXJlIGlzIG5vIHJlY29n bml0aW9uIChiZXlvbmQgbGlwLXNlcnZpY2UgaW4gT1BHUCkgdGhhdCB0aGUgcGVyc29uIGlzIGhp cyBvd24gdWx0aW1hdGUgYXV0aG9yaXR5LCBhbmQgY2FuIGNob29zZSB0byBhY2NlcHQgYW55dGhp bmcgaGUgd2FudHMgZXZlbiBpZiBpdCBkb2Vzbid0IG1lZXQgdGhlIHN0YW5kYXJkJ3MgY29uY2Vw dCBvZiAiYWNjZXB0YWJpbGl0eSIuDQoNClNvY2lldGllcyBkb24ndCBoYXZlIHJlcHV0YXRpb24g YmVjYXVzZSB0aGV5IG5lZWQgaWRlbnRpdHksIHRoZXkgaGF2ZSBpZGVudGl0eSBiZWNhdXNlIHRo ZXkgbmVlZCByZXB1dGF0aW9uLiAgQSBwZXJzb24gbGVnaXRpbWF0ZWx5IGhhcyBtYW55IG1vcmUg cmVwdXRhdGlvbnMgdGhhbiBqdXN0IHRoZSBvbmVzIGxhYmVsZWQgd2l0aCB0aGUgbGFiZWwgdGhl IHN0YXRlIHVzZXMsIGFuZCBhIHBlcnNvbiBsZWdpdGltYXRlbHkgaGFzIGEgbmVlZCB0byBpc3N1 ZSBjcmVkZW50aWFscyB3aXRoaW4gaGlzIG93biBkb21haW4uDQoNClRoaXMgbWVhbnMgdGhhdCB0 aGVyZSBleGlzdCBsZWdpdGltYXRlIHJlYXNvbnMgdG8gc251YiB0aGUgYXV0aG9yaXRhdGl2ZSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBpbmR1c3RyeSwgZXNwZWNpYWxseSBnaXZlbiBzdGFuZGFy ZCBwcm90b2NvbHMgdGhhdCBwZXJtaXQgYXNzZXJ0aW9ucyBmcm9tIG9uZSBhbmQgb25seSBvbmUg Y2hhaW4gb2YgYXV0aG9yaXR5Lg0KDQogoFRoZXJlIGFyZSByZWFzb25zIHdoeQ0KPiBTL01JTUUg YW5kIFBHUCBoYXZlbid0IGJlY29tZSBraWxsZXIgYXBwcyAoYW5kIHNvbWVvbmUgd2hvIGtub3dz IG11Y2gNCj4gbW9yZSBhYm91dCB0aGVtIHRoYW4gSSBjYW4gbGF5IHRoZW0gb3V0KSwgYnV0IGxh Y2sgb2YgYSBoZWFkZXIgYnkNCj4gd2hpY2ggdG8gY29tbXVuaWNhdGUgTVVBIGNhcGFiaWxpdGll cyBpcyBub3Qgb25lIG9mIHRoZW0gLS0gd2Ugd291bGQNCj4gaGF2ZSBzb2x2ZWQgdGhhdCBsb25n IGFnbyBpZiBpdCBoYWQgYmVlbi4NCg0KSSBtZW50aW9uZWQgb25lIHJlYXNvbiBhYm92ZS4gIE90 aGVycyBhcmU6DQoyKSB0aGUgYXJ0aWZpY2lhbCBhbmQgdW5uZWNlc3NhcnkgdGVycm9yIGluZHVj ZWQgYnkgbWlzZ3VpZGVkLWJ5LUlFVEYgaW1wbGVtZW50b3JzIHdobyBwcmVzZW50IHVudHJ1c3Rl ZCBjaGFpbnMgYXMgc29tZWhvdyBsZXNzIHNlY3VyZSB0aGFuIG5vIHNpZ25hdHVyZSBhdCBhbGwu DQozKSB0aGUgbGFjayBvZiB0cmFuc3BhcmVudCBvcGVyYXRpb24sIGl0J3MgYW5vdGhlciBzdGVw IGluIHRoZSByb3RlIHByb2Nlc3Mgb2YgZ2V0dGluZyBzZXQgdXAgdGhhdCBwZW9wbGUgZG9uJ3Qg cGxhbiB0aW1lIGZvci4NCjQpIFRoZSBleGhvcnRhdGlvbiBpbiBQR1AncyBkb2N1bWVudGF0aW9u IHRvIGtlZXAgeW91ciBwcml2YXRlIGtleSBvbiBhIHNpbmdsZSBtZWRpdW0sIHdpdGggbm8gcHJv dmlzaW9ucyBmb3Igd2hhdCB0byBkbyBpZiB0aGF0IG1lZGl1bSBpcyBsb3N0LiAgSWYgeW91IChs aWtlIG1lKSBoYWQgeW91ciBwcml2YXRlIGtleSBvbiBhIGZsb3BweSBkaXNrIHdheSBiYWNrIHdo ZW4sIHlvdSBwcm9iYWJseSAobGlrZSBtZSkgbG9zdCBpdCB0byBiYWQgc2VjdG9ycyBhdCBzb21l IHBvaW50LCBhbmQgKGxpa2UgbWUpIGxvc3QgYWNjZXNzIHRvIGluZm9ybWF0aW9uIGVuY3J5cHRl ZCB0byBpdC4gIElmIHdlIGNhbid0IGd1YXJhbnRlZSB0aGF0IHRoZSB1c2VyIGRhdGEgd2lsbCBi ZSBhY2Nlc3NpYmxlLCBpdCdzIG5vdCBzZWN1cmUuDQo1KSBUaGUgYXV0aG9yaXRhcmlhbiBtb2Rl bCB3aGljaCBQS0lYLVdHIGhhcyBpbXByb3Blcmx5IGFzc3VtZWQgZml0cyByZWFsaXR5LCB3aGVu IGluIHJlYWxpdHkgc29jaWV0eSBpcyBtdWNoIG1vcmUgZGVtb2NyYXRpYyB3aXRoIGl0cyBwZXR0 eSBmaWVmZG9tcy4NCjYpIFRoZSBpbmFiaWxpdHkgb2YgcGVvcGxlIHRvIHBsYXkgYXJvdW5kIHdp dGggQVNOLjEtYmFzZWQgYXV0aGVudGljYXRpb24gdGVjaG5vbG9naWVzIHdpdGhvdXQgZmVlbGlu ZyBsaWtlIGV2ZXJ5IHRpbWUgdGhleSBjbGlja2VkIHRoZSAic2lnbiIgYnV0dG9uIHRoZXknZCBq dXN0IHNvbWVob3cgc29sZCB0aGVpciBmaXJzdGJvcm4sIGFnYWluIGR1ZSB0byB0aGUgbWlzZ3Vp ZGVkLWJ5LUlFVEYgaW1wbGVtZW50b3JzIHdobyBpbmZsaWN0IHRlcnJvciBpbiB0aGVpciB1c2Vy IGludGVyZmFjZXMuDQoNClRoZSBpZGVhIHRoYXQgdW5hdXRoZW50aWNhdGVkIGNyeXB0b2dyYXBo eSBpcyB1c2VsZXNzIGlzIGZhbHNlLiAgQW1vbmcgb3RoZXIgdGhpbmdzLCBpdCBlbmZvcmNlcyB0 aGF0IGF0dGFja3Mgb24gdGhlIHByaXZhY3kgb2YgdGhlIGNvbnRlbnQgaGF2ZSBhIG1pbmltdW0g d29yayBmYWN0b3Igd2hpY2ggbXVzdCBiZSBzdXJwYXNzZWQuICBJbiB0aGUgcmVhbCB3b3JsZCwg dGhpcyBtZWFucyB0aGF0IGEgc3RhdGUgd291bGQgYWN0aXZlbHkgaGF2ZSB0byBhdHRlbXB0IHRv IGF0dGFjayBhIHBlcnNvbiB3aXRoIGFuIE1pdE0gZW1haWwgcmVsYXkuICBUaGlzIGlzIGNlcnRh aW5seSBkb2FibGUsIGJ1dCBJIGRvbid0IHRoaW5rIGl0J3Mgc29tZXRoaW5nIHRoYXQgd2UgY2Fu IHJlYWxseSBwcmV2ZW50LiAgSW4gYWRkaXRpb24sIGV2ZW4gbm9uLWF1dGhvcml0YXJpYW4gcmVn aW1lcyBoYXZlIGxlZ2l0aW1hdGUgbGF3LWVuZm9yY2VtZW50IG5lZWRzIHRvIGludGVyY2VwdCBj b21tdW5pY2F0aW9ucy4gIEFuZCBldmVuIHRoZW4sIG9uY2UgYXV0aG9yaXRhdGl2ZSBjZXJ0aWZp Y2F0aW9ucyBvciBleHRlcm5hbC1jaGFubmVsIGZpbmdlcnByaW50cyBhcmUgZXhjaGFuZ2VkLCBp dCBjb3VsZCBiZSBkZXRlY3RlZCBhbmQgaXRzIHV0aWxpdHkgd291bGQgYmUgc2V2ZXJlbHkgbGlt aXRlZC4NCg0KVGhlIGlkZWEgdGhhdCAiU2VsZiBBc3NlcnRpb25zIGFyZSBOdWxsIEFzc2VydGlv bnMiIGlzIGZhbHNlLiAgU2VsZi1hc3NlcnRpb25zIHBlcm1pdCB0aGUgcGVyc29uLCB0aGUgU2Vs ZiwgdG8gY29tbXVuaWNhdGUgaW5mb3JtYXRpb24gdGhhdCB0aGV5IHNheSBhYm91dCB0aGVtc2Vs dmVzLCByYXRoZXIgdGhhbiBzb2xlbHkgd2hhdCBvdGhlciBwZW9wbGUgaGF2ZSBzYWlkIGFib3V0 IHRoZW0uICBUaGUgaWRlYSBvZiBwcm92aWRpbmcgb25seSBhIHNpbmdsZSBjZXJ0aWZpY2F0ZSBj aGFpbiBpcyBiYWQsIGJlY2F1c2UgaXQgZXZlbiBsaW1pdHMgdGhlIGluZm9ybWF0aW9uIGEgcGVy c29uIGNhbiBwdXQgZm9ydGggdG8gd2hhdCAtb25lLSBvdGhlciBwZXJzb24gaGFzIHNhaWQgYWJv dXQgaGltLg0KDQpUaGUgd29ybGR2aWV3IHRoYXQgU0FhTkEgc3Bhd25lZCBoYXMgc3RpZmxlZCB0 aGUgYWR2YW5jZW1lbnQgb2YgaW5jcmVtZW50YWwsIGVmZmVjdGl2ZSwgdXNlZnVsIGNyeXB0b2dy YXBoaWMgdGVjaG5vbG9neS4gIFRoZSBpbmRvY3RyaW5hdGlvbiBpbnRvIHRoZSAiY2VydGlmaWNh dGlvbnMgYXJlIHRoZSBvbmx5IHdheSB0byBrbm93IHlvdSdyZSB0YWxraW5nIHRvIHdobyB5b3Ug dGhpbmsgeW91J3JlIHRhbGtpbmcgdG8iIHdvcmxkdmlldyBiZWdzIHRoZSBxdWVzdGlvbiwgImRv IHdlIGFsd2F5cyBuZWVkIHRvIGtub3cgcHJlY2lzZWx5IHdobyB3ZSdyZSB0YWxraW5nIHRvPyIg IEFuZCBJIGFzc2VydCB0aGUgYW5zd2VyIGlzIG5vLiAgSWYgaXQgd2VyZSB5ZXMsIHdlIHdvdWxk bid0IGhhdmUgdW5lbmNyeXB0ZWQgSFRUUCBnb2luZyBvdmVyIHRoZSBuZXR3b3JrLiAgVGhlIG1h bmRhdGUgdG8gb25seSBldmVyIGdydWRnaW5nbHkgcGVybWl0IEFic29sdXRlbHkgQ29ycmVjdCBz ZW1hbnRpY3MgdG8gYmUgcHJlc2VudGVkIHdpdGhvdXQgVUkgZmFpbHVyZSBwcmV2ZW50cyBlZmZl Y3RpdmUgYXBwbGljYXRpb24gb2YgdHJhbnNwYXJlbnQsIG9wcG9ydHVuaXN0aWMgY3J5cHRvZ3Jh cGhpYyBpbXBsZW1lbnRhdGlvbnMgd2l0aCBlZmZlY3RpdmUgb24tcmFtcHMgaW50byBBdXRob3Jp dGF0aXZlIFNlbWFudGljcy4NCg0KVGh1cyBpcyB0aGUgaW5kb2N0cmluYXRpb24gb2YgdGhlIFBL SSBQcmllc3Rob29kLiAgUGV0ZXIgR3V0bWFubiAoVS4gb2YgQXVja2xhbmQgTlopIGhhcyByZWZl cnJlZCB0byB0aGlzIGluZG9jdHJpbmF0aW9uIGFzICJQS0kgbWUgaGFyZGVyIi4gIFRvIG1ha2Ug dGhlIHdvcmxkIGEgYmV0dGVyIGFuZCBtb3JlIHNlY3VyZSBwbGFjZSwgaXQgbXVzdCBiZSBzaGFr ZW4uDQoNCi1LeWxlIEgNCg== --gmsm1.9.5eqgyrumc383trqtx7pki2 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Verify This Message with Penango.p7s" Content-Description: S/MIME Cryptographic Signature Content-Type: application/pkcs7-signature; name="Verify This Message with Penango.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINBDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGyDCCBbCg AwIBAgICCMQwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDA2MDUxNTE0NDlaFw0xMjA2MDYwMTUyNThaMIHBMSAwHgYDVQQNExcyMDc2MDMtYTJBNUY2Qk5y Q004a3pUcjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBK b3NlMS0wKwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxFjAUBgNV BAMTDUt5bGUgSGFtaWx0b24xITAfBgkqhkiG9w0BCQEWEmFlcm93b2xmQGdtYWlsLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKihuEdUtsm9bDAGpxq1L6UaToHDtYiDtMNY9kQs Xi3UNwNl1lOdiSJ5bWEB9rW39ApoAzgx2m7qxMo9/tj1HD4G4laWxr4mv6Zz7fFW9TwJKGAOU+aH fVBoB981MJzRatpbl+hh7KPX7Yxs7T5n8aoVk+uhDhQnutnRge+hTVTls0ETosKJkb/zs7rDNE7U 1Rs0OL6NMi1EBRowPqoROFSzB1PnxyNwEzbcIlLCAHTOpKEwiHpe/96VlubEJ6OdsufDXSAqx46v RFPaylY4FzH6UENeHxqS6BRa4qDHnRX0d6pcL2rCDqB2HR7Gp+uIgbZxnBBLTNG7zwxY8xlu3t0C AwEAAaOCAvswggL3MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDAdBgNVHQ4EFgQU15W7wxiz14ugNcMqN8b+nI26JkUwHwYDVR0jBBgwFoAUrlWD b+wxyrn3HfqvazHzyB3jrLswHQYDVR0RBBYwFIESYWVyb3dvbGZAZ21haWwuY29tMIIBQgYDVR0g BIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t L2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqB kUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRo ZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDov L3d3dy5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDov L29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0S BBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQBnY5m1aF0l 8iRgGo1BHSBqfXbcijgssD6IY/FInZ0WE76eTBXvm3EJac7bw5ZegnurckEybYfOW21LrFgbsKHM nviFSMXhrGZWNsian4JOutmQS61MHjLg+qthfpvPtiYBXW/eqlTTovC0vqxqGmgU8qTBPvWJn+pe AnST/c/eOqhGKbC2L+yAOAUIIaGNVyiChu1aXu/nh3+/37mRzixiMAGDmTS8fzrCmk2rEInw7bJO syom5fb48mt9Gz1DxK+yvQcR4agPDZOWqnpf1LycPScE5enZOY3aNxqd2qJLko48Vz4acwCRKWMx AiYmk/ImAwN6LWWKZatQdHbZoTZUMYICfDCCAngCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQICCMQwCQYFKw4DAhoFAKCBvjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjAyMTcyMzI3MjJaMCMGCSqGSIb3DQEJBDEWBBTKJ/92HCDXGXU8H078zj5o 4fpiEDBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEB BQAEggEAJXLn+noU1/zYaH5la2rqcuOfnu3D91bR9LJ3kzvhlUhsxk+QToRjYpvv1NPJhwQGG8st Do6xaLMwFybWIrkiyn+MYTeTB/3Ri0/qlDQbA9u8jYfPO3oATgRdVCBzE5YoGpMjJ9mfi/La3j53 NmtRjWp2yyFAQf9VKk1p7FH9OPuSXB8aTXyHGDflxtblOV8bQ9oI3FT0SJIcq9vUUceAAcgXueMc +RRKAPw1mWW2lSrHyjieYo39ElpJfSV1tyiifEgWddmq2ie7EkipnR3cNYTj/OTbltWZI/WGixpj 64hLTdC1VMJ19J4WjcQ3yACjvItwqN19bOXQFvWXbJ6q5QAAAAAAAA== --gmsm1.9.5eqgyrumc383trqtx7pki2-- From adam@cypherspace.org Fri Feb 17 15:40:30 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0489021F84D0 for ; Fri, 17 Feb 2012 15:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENXMLTb4m15a for ; Fri, 17 Feb 2012 15:40:28 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id A7D7B21F842C for ; Fri, 17 Feb 2012 15:40:28 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Lk8Go-1SUrM82pWE-00bR1Z; Fri, 17 Feb 2012 18:40:27 -0500 Received: by iagf6 with SMTP id f6so6056402iag.31 for ; Fri, 17 Feb 2012 15:40:26 -0800 (PST) Received-SPF: pass (google.com: domain of adam@cypherspace.org designates 10.42.157.133 as permitted sender) client-ip=10.42.157.133; Authentication-Results: mr.google.com; spf=pass (google.com: domain of adam@cypherspace.org designates 10.42.157.133 as permitted sender) smtp.mail=adam@cypherspace.org Received: from mr.google.com ([10.42.157.133]) by 10.42.157.133 with SMTP id d5mr11266589icx.46.1329522026388 (num_hops = 1); Fri, 17 Feb 2012 15:40:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.157.133 with SMTP id d5mr8878799icx.46.1329522026369; Fri, 17 Feb 2012 15:40:26 -0800 (PST) Received: by 10.42.244.68 with HTTP; Fri, 17 Feb 2012 15:40:26 -0800 (PST) In-Reply-To: <4F3EE16A.3040507@cs.tcd.ie> References: <4F3C04C9.7040601@cs.tcd.ie> <4F3D00D7.8020305@cs.tcd.ie> <4F3EE16A.3040507@cs.tcd.ie> Date: Sat, 18 Feb 2012 00:40:26 +0100 Message-ID: From: Adam Back To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V02:K0:atvXH8w1Cz6M8Qu7x5fqWYFLasTudRw6+/iZW4sWyYU +InsL2JExgQgnDZNs482eCIZnys12MqAgkWrRIqlZVUzW7rGXj HMOoaUbfivYn1lbnWdQ6m21ATfJjfFw0bmFvQYKjTM8RlBDmO/ dKf9uai2YbVb3bsmRVJff5kysrPurQmNBrVELEnXWwOeSJqD+b eNl3TeLkv0T/aT1cbBfqaNOvVuTp5iHSNjAFaLBD127V6huCc7 4CB/Bc3mjsMw3qTdJhPGwji/eikeZHJdQn7w+oqXxN0L3CdNnk y0q3p06WUfM9GEKuqldGRj6A6y6m37FAEn1WT3K3uVquMKldKj IvjERneeMIKaA9/KQMPGkoFdEwRjtquEi8sv3dA/iYMBPHAoIw TN0k/PdIA28g4ImzH2i3Cre4F6AfZQGlK24pJwB81uwgrJ4eSl Ev0Z4 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 23:40:30 -0000 While it doesnt hurt as a partial sanity check, but with a huge false negative rate (ie it wont complain many many times even though the entropy is too small because it cant measure entropy, just the occasional side effect that two computers generated the same value), it doesnt robustly fix the problem which is the entropy of the device RNG is woefully small. eg say the entropy is 20-bits and there are enough clients participating that mostly you get a collision for any of the 2^20 (1million) keys. So then you tell it to try again, and it repeatedly does until there is no collision. All you've done is add a new entry to your previously seen public key table on the server. No entropy was added. You cant really (securely) send entropy over the network to a device with n= o entropy because an eavesdropper can read whatever you send it. There is another RNG problem also where if you add entropy in too small chunks the attacker can also brute force in stages. The yarrow design was supposed to defend against that. eg consider you break in and copy rng state, then the user adds 32-bits, draws one externally published or verifiable output - eg a nonce or encryption using a random key etc, then adds another 32-bits and repeat. Well that remains insecure indefinitely because the attacker can brute force each 32-bits independently. As a last resort defense its probably better to send the client some randomness in the clear, or encrypted with a key exchange depending on what randomness it has - at least then in the off chance that the attacker misse= d those messages, you retain some security rather than going forward with an insecure public key... But really the device itself should be tracking what entropy it has as it is the only device in a position to know that and refraining from generating cryptographic keys with under 128-bits of entropy... Adam On 18 February 2012 00:23, Stephen Farrell wrot= e: > > Hiya, > > > On 02/17/2012 11:11 PM, Adam Back wrote: >> >> I dont think this is going to be very robust because the fact that the >> entropy seeding is so bad that some implementations are generating >> literally the same p value (but seemingly different q values) I would >> think you could view the fact that this can be >> detected and efficiently exploited via batch GCD as an indication of an >> even >> bigger problem. >> >> Namely if the seeding is that bad you could outright compute all possibl= e >> values of p even for cases where p was not shared, by running through th= e >> evidently small by cryptographic standards number of possible PRNG >> states... >> >> Then you might be looking at more than 1% or whatever the number is that >> literally collide in specific p value. =A0Assuming p is more vulnerable = than >> q, you could then use the same batch GCD to test. > > > Sure. But wouldn't this protocol still help then? Assuming that > protocol clients don't ignore the known-bad answers, they'd > hopefully iterate until they get a not-known-bad key one way or > another. > > I think so, but maybe you're seeing something I'm not. > > Something not that clear in the -00 is that the responder here > can supply random bits as a side effect of answering the > query. (The -01 will make this clearer when its ready.) > > > S. > >> >> Adam >> >> On 16 February 2012 14:12, Stephen Farrell >> =A0wrote: >>> >>> >>> Dunno if anyone else thinks this might be interesting >>> but I do:-) >>> >>> So I sketched out an initial idea for how it might fit >>> in here. [1] >>> >>> Comments welcome. >>> >>> S. >>> >>> [1] http://www.ietf.org/id/draft-farrell-kc-00.txt >>> >>> >>> On 02/15/2012 07:17 PM, Stephen Farrell wrote: >>>> >>>> >>>> >>>> Hiya, >>>> >>>> I guess the recent publications about common factors [1,2] >>>> are something else that this group might want to consider. >>>> >>>> I wonder if an rsa modulus checker protocol might help or >>>> something. Not sure if that's something that could be run >>>> quickly enough though, other than for the straight >>>> duplicates or dumbass things with small factors you should >>>> spot yourself. Anyone know? >>>> >>>> Or maybe you could register your public key and get a >>>> nonce, then come back periodically to see if any problems >>>> have been detected for your key. >>>> >>>> And yes, better prngs are needed, but there'll probably >>>> always be bad ones out there. >>>> >>>> S. >>>> >>>> [1] http://eprint.iacr.org/2012/064 >>>> [2] >>>> >>>> >>>> http://it.slashdot.org/story/12/02/15/1540212/factorable-keys-twice-as= -many-but-half-as-bad >>>> >>>> _______________________________________________ >>>> therightkey mailing list >>>> therightkey@ietf.org >>>> https://www.ietf.org/mailman/listinfo/therightkey >>>> >>> _______________________________________________ >>> therightkey mailing list >>> therightkey@ietf.org >>> https://www.ietf.org/mailman/listinfo/therightkey >> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> > From nico@cryptonector.com Fri Feb 17 16:03:48 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9E321F86C9 for ; Fri, 17 Feb 2012 16:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBlPTchmpgTH for ; Fri, 17 Feb 2012 16:03:48 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 4E98821F86C8 for ; Fri, 17 Feb 2012 16:03:48 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id D4E223B8076 for ; Fri, 17 Feb 2012 16:03:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=c2Nak1vsDVJSNjG2f044gRYSwuE/LW77wqcgrq7y6V/A hPyRlzHsqN7E/bky4HDN4pD2Kk9jPrAxkOB/8KGv3PJOSW0EL2TBtgyKDMtdz3er VgY06RqjojW2jw3E58EVDfzhU/xPOQzyJRq2hdDhproNAb4TIAz/o1dPyrcxuaU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=k8lY5wObo0h2Kc8RdJShf6R6Z1A=; b=ZtcD0rrDGT/ Y4I9dmtPiy5HXAjAaFF8kKm+bSyWv3gZd3UnaSYsrFZgB5U72arOl99l1hTXfQkt Dzqm+adf6nrOLhRIM0K5wl8BlWyobfYrAAn+Z5SNsWT54EYD2csqwQSWJzG2bLvF 3hNBTk+0vV4PONkuRKZE21dWMljL67dg= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id BCF2A3B8069 for ; Fri, 17 Feb 2012 16:03:47 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so4449925pbc.31 for ; Fri, 17 Feb 2012 16:03:47 -0800 (PST) Received-SPF: pass (google.com: domain of nico@cryptonector.com designates 10.68.216.134 as permitted sender) client-ip=10.68.216.134; Authentication-Results: mr.google.com; spf=pass (google.com: domain of nico@cryptonector.com designates 10.68.216.134 as permitted sender) smtp.mail=nico@cryptonector.com Received: from mr.google.com ([10.68.216.134]) by 10.68.216.134 with SMTP id oq6mr36118914pbc.118.1329523427448 (num_hops = 1); Fri, 17 Feb 2012 16:03:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.216.134 with SMTP id oq6mr29133720pbc.118.1329523427355; Fri, 17 Feb 2012 16:03:47 -0800 (PST) Received: by 10.68.136.4 with HTTP; Fri, 17 Feb 2012 16:03:47 -0800 (PST) In-Reply-To: References: <12020712051780_4AE3A@oregon.uoregon.edu> <64BDD821-80B9-4FF6-9E91-72A3A515AA77@gmail.com> <4F332B39.7090805@cs.tcd.ie> Date: Fri, 17 Feb 2012 18:03:47 -0600 Message-ID: From: Nico Williams To: Kyle Hamilton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "therightkey@ietf.org" , Peter Gutmann , Stephen Farrell Subject: Re: [therightkey] Secure e-mail, and why it's not an intractable problem X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 00:03:49 -0000 On Fri, Feb 17, 2012 at 5:27 PM, Kyle Hamilton wrote: > > On Wed, Feb 8, 2012 at 9:35 PM, Nico Williams wro= te: >> >> E-mail is not an online protocol between two MUAs. =C2=A0When you send a= n >> e-mail your MUA is not talking directly to the recipient's MUA, and >> there are no automated replies except for vacation replies. > > > That last assertion is demonstrably false. =C2=A0Among other things, ther= e's the > "return receipt requested" processor. =C2=A0There's the "mailing list > distribution autoresponder". =C2=A0There is what I'm developing, which is= exactly > what I'm talking about. Sigh. I think I failed to finish that sentence. What I meant to say is that there are no unattended standard (de facto or otherwise) protocols based on e-mail that could be used to do what OTR does. Yes, such protocols are feasible. But there's a reason we've got them, and use them for IM (OTR) and not so much for e-mail: users wouldn't have the patience for an e-mail OTR. Nico -- From stephen.farrell@cs.tcd.ie Fri Feb 17 16:12:27 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B861D11E80AF for ; Fri, 17 Feb 2012 16:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYx3rextKFbs for ; Fri, 17 Feb 2012 16:12:26 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3306811E80AE for ; Fri, 17 Feb 2012 16:12:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 77DAC171D76; Sat, 18 Feb 2012 00:12:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1329523944; bh=WHVPPYUzTBUxtq U07Q96nt22Fyrn8zt4Wpq6vMjhFbQ=; b=2iKgE0dOBn39o+hD3+8UMFzEoQ4FND 1WBCKkv8+Vd7DsABETPFB3bEcDg4KpzpTB/pL4m+acgLMztcJsZXiEmFqg/+5N6Z gVjoRjMFGKTvSkoCPO1hOOvcAVIrh+MUOeZzXidNvry4OF/OwcyywmRhkTAOgCQ4 fnA9Ys+cb+GspPz0rUwlby2IM7oPuGC/uMwLzoON+jnB0pOJKZMw47nOzB29fBX7 ov/0StpSTtwUhTckAAp16ISfyucyJsI4AbVsntpwChG6T2g0c48hlQdg7xD7d4NM tNO/Kt28LKF1MueIXgXHx1PzTsh0wC4MNQwI0cXqpLzLUw/qkgYc6BOg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 4jF2eOnpETAT; Sat, 18 Feb 2012 00:12:24 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.41.9.27]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2EBEA171D0C; Sat, 18 Feb 2012 00:12:24 +0000 (GMT) Message-ID: <4F3EECDD.4060205@cs.tcd.ie> Date: Sat, 18 Feb 2012 00:12:13 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Adam Back References: <4F3C04C9.7040601@cs.tcd.ie> <4F3D00D7.8020305@cs.tcd.ie> <4F3EE16A.3040507@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 00:12:27 -0000 Some good points. On 02/17/2012 11:40 PM, Adam Back wrote: > While it doesnt hurt as a partial sanity check, but with a huge false > negative rate (ie it wont complain many many times even though the entropy > is too small because it cant measure entropy, just the occasional side > effect that two computers generated the same value), it doesnt robustly fix > the problem which is the entropy of the device RNG is woefully small. > > eg say the entropy is 20-bits and there are enough clients participating > that mostly you get a collision for any of the 2^20 (1million) keys. So > then you tell it to try again, and it repeatedly does until there is no > collision. All you've done is add a new entry to your previously seen > public key table on the server. No entropy was added. That assumes that the client doesn't get more random bits as time goes on. In practice I'd say getting more bits is quite likely, but whether those would be enough to make a difference if we really start with only 20 bits is hard to say. But that's probably a minor effect compared to sending random bits. > You cant really (securely) send entropy over the network to a device with no > entropy because an eavesdropper can read whatever you send it. I disagree. I can often send entropy in practice securely but with no guarantees, (on that we agree). That's still better than not doing it in most cases. I'd be pretty confident that the majority of devices with not so great key generation could be helped by something like this. > > There is another RNG problem also where if you add entropy in too small > chunks the attacker can also brute force in stages. The yarrow design was > supposed to defend against that. eg consider you break in and copy rng > state, then the user adds 32-bits, draws one externally published or > verifiable output - eg a nonce or encryption using a random key etc, then > adds another 32-bits and repeat. Well that remains insecure indefinitely > because the attacker can brute force each 32-bits independently. > > As a last resort defense its probably better to send the client some > randomness in the clear, or encrypted with a key exchange depending on what > randomness it has - at least then in the off chance that the attacker missed > those messages, you retain some security rather than going forward with an > insecure public key... > > But really the device itself should be tracking what entropy it has as > it is the only device in a position to know that and refraining from > generating cryptographic keys with under 128-bits of entropy... Right. But we've seen that device keep not doing it right locally, hence the idea of trying to help globally. S > > Adam > > On 18 February 2012 00:23, Stephen Farrell wrote: >> >> Hiya, >> >> >> On 02/17/2012 11:11 PM, Adam Back wrote: >>> >>> I dont think this is going to be very robust because the fact that the >>> entropy seeding is so bad that some implementations are generating >>> literally the same p value (but seemingly different q values) I would >>> think you could view the fact that this can be >>> detected and efficiently exploited via batch GCD as an indication of an >>> even >>> bigger problem. >>> >>> Namely if the seeding is that bad you could outright compute all possible >>> values of p even for cases where p was not shared, by running through the >>> evidently small by cryptographic standards number of possible PRNG >>> states... >>> >>> Then you might be looking at more than 1% or whatever the number is that >>> literally collide in specific p value. Assuming p is more vulnerable than >>> q, you could then use the same batch GCD to test. >> >> >> Sure. But wouldn't this protocol still help then? Assuming that >> protocol clients don't ignore the known-bad answers, they'd >> hopefully iterate until they get a not-known-bad key one way or >> another. >> >> I think so, but maybe you're seeing something I'm not. >> >> Something not that clear in the -00 is that the responder here >> can supply random bits as a side effect of answering the >> query. (The -01 will make this clearer when its ready.) >> >> >> S. >> >>> >>> Adam >>> >>> On 16 February 2012 14:12, Stephen Farrell >>> wrote: >>>> >>>> >>>> Dunno if anyone else thinks this might be interesting >>>> but I do:-) >>>> >>>> So I sketched out an initial idea for how it might fit >>>> in here. [1] >>>> >>>> Comments welcome. >>>> >>>> S. >>>> >>>> [1] http://www.ietf.org/id/draft-farrell-kc-00.txt >>>> >>>> >>>> On 02/15/2012 07:17 PM, Stephen Farrell wrote: >>>>> >>>>> >>>>> >>>>> Hiya, >>>>> >>>>> I guess the recent publications about common factors [1,2] >>>>> are something else that this group might want to consider. >>>>> >>>>> I wonder if an rsa modulus checker protocol might help or >>>>> something. Not sure if that's something that could be run >>>>> quickly enough though, other than for the straight >>>>> duplicates or dumbass things with small factors you should >>>>> spot yourself. Anyone know? >>>>> >>>>> Or maybe you could register your public key and get a >>>>> nonce, then come back periodically to see if any problems >>>>> have been detected for your key. >>>>> >>>>> And yes, better prngs are needed, but there'll probably >>>>> always be bad ones out there. >>>>> >>>>> S. >>>>> >>>>> [1] http://eprint.iacr.org/2012/064 >>>>> [2] >>>>> >>>>> >>>>> http://it.slashdot.org/story/12/02/15/1540212/factorable-keys-twice-as-many-but-half-as-bad >>>>> >>>>> _______________________________________________ >>>>> therightkey mailing list >>>>> therightkey@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/therightkey >>>>> >>>> _______________________________________________ >>>> therightkey mailing list >>>> therightkey@ietf.org >>>> https://www.ietf.org/mailman/listinfo/therightkey >>> >>> _______________________________________________ >>> therightkey mailing list >>> therightkey@ietf.org >>> https://www.ietf.org/mailman/listinfo/therightkey >>> >> > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From stephen.farrell@cs.tcd.ie Sat Feb 18 12:53:05 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A51421E8015 for ; Sat, 18 Feb 2012 12:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjYod9WcA5r2 for ; Sat, 18 Feb 2012 12:53:04 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A60EC21E8017 for ; Sat, 18 Feb 2012 12:53:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 11D8F171D03 for ; Sat, 18 Feb 2012 20:53:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1329598381; bh=yaopbb13kfRM0w HBgowMKjOO6IQQomyMRWlUHYEvi6o=; b=WBWcIkruMvxVnEtEAWbiGzFdUHitMy lI+ZV7NfBt5w2KdQSWyJpDoE87cCLpF9YH1vwPoOBElkcneY+fz1d6YYumfu1yeG RMyg4YvyJMROzEgfnzgVreP+igC4xTnEPaAq++56xJa8AWmHNu8w6gl0/auKP2QU CyRJHtB1pn8i8F8OMJtRwN9y96yMJBGS09sAtiKzTSVrRH/XAF7J31Tyhq4M0nzB e4iuVP3yV2s8epF46rcZ/+mY3SZgaZqzu6ekccNqPA4LLvzdi/CBIy67SeNXGrby DLgQlOWcAuoBvmM1Fr8CheVT5jV1YgK/KP9th5Sd0MmcevXNl8CVnduQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id mkJilW42MA-y for ; Sat, 18 Feb 2012 20:53:01 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.41.12.219]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1A7BC171C3D for ; Sat, 18 Feb 2012 20:53:01 +0000 (GMT) Message-ID: <4F400FAC.2090100@cs.tcd.ie> Date: Sat, 18 Feb 2012 20:53:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <4F3C04C9.7040601@cs.tcd.ie> <4F3D00D7.8020305@cs.tcd.ie> <4F3EE16A.3040507@cs.tcd.ie> <4F3EECDD.4060205@cs.tcd.ie> In-Reply-To: <4F3EECDD.4060205@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 20:53:05 -0000 So I did a bit on this yesterday and today and now there's a good bit more detail [1] to beat up on if someone's interested. :-) S. [1] http://tools.ietf.org/html/draft-farrell-kc-01 On 02/18/2012 12:12 AM, Stephen Farrell wrote: > > Some good points. > > On 02/17/2012 11:40 PM, Adam Back wrote: >> While it doesnt hurt as a partial sanity check, but with a huge false >> negative rate (ie it wont complain many many times even though the >> entropy >> is too small because it cant measure entropy, just the occasional side >> effect that two computers generated the same value), it doesnt >> robustly fix >> the problem which is the entropy of the device RNG is woefully small. >> >> eg say the entropy is 20-bits and there are enough clients participating >> that mostly you get a collision for any of the 2^20 (1million) keys. So >> then you tell it to try again, and it repeatedly does until there is no >> collision. All you've done is add a new entry to your previously seen >> public key table on the server. No entropy was added. > > That assumes that the client doesn't get more random bits as time goes > on. In practice I'd say getting more bits is quite likely, but whether > those would be enough to make a difference if we really start with only > 20 bits is hard to say. But that's probably a minor effect compared to > sending random bits. > >> You cant really (securely) send entropy over the network to a device >> with no >> entropy because an eavesdropper can read whatever you send it. > > I disagree. I can often send entropy in practice securely but > with no guarantees, (on that we agree). > > That's still better than not doing it in most cases. I'd be pretty > confident that the majority of devices with not so great key > generation could be helped by something like this. > >> >> There is another RNG problem also where if you add entropy in too small >> chunks the attacker can also brute force in stages. The yarrow design was >> supposed to defend against that. eg consider you break in and copy rng >> state, then the user adds 32-bits, draws one externally published or >> verifiable output - eg a nonce or encryption using a random key etc, then >> adds another 32-bits and repeat. Well that remains insecure indefinitely >> because the attacker can brute force each 32-bits independently. >> >> As a last resort defense its probably better to send the client some >> randomness in the clear, or encrypted with a key exchange depending on >> what >> randomness it has - at least then in the off chance that the attacker >> missed >> those messages, you retain some security rather than going forward >> with an >> insecure public key... >> >> But really the device itself should be tracking what entropy it has as >> it is the only device in a position to know that and refraining from >> generating cryptographic keys with under 128-bits of entropy... > > Right. But we've seen that device keep not doing it right locally, > hence the idea of trying to help globally. > > S > >> >> Adam >> >> On 18 February 2012 00:23, Stephen Farrell >> wrote: >>> >>> Hiya, >>> >>> >>> On 02/17/2012 11:11 PM, Adam Back wrote: >>>> >>>> I dont think this is going to be very robust because the fact that the >>>> entropy seeding is so bad that some implementations are generating >>>> literally the same p value (but seemingly different q values) I would >>>> think you could view the fact that this can be >>>> detected and efficiently exploited via batch GCD as an indication of an >>>> even >>>> bigger problem. >>>> >>>> Namely if the seeding is that bad you could outright compute all >>>> possible >>>> values of p even for cases where p was not shared, by running >>>> through the >>>> evidently small by cryptographic standards number of possible PRNG >>>> states... >>>> >>>> Then you might be looking at more than 1% or whatever the number is >>>> that >>>> literally collide in specific p value. Assuming p is more vulnerable >>>> than >>>> q, you could then use the same batch GCD to test. >>> >>> >>> Sure. But wouldn't this protocol still help then? Assuming that >>> protocol clients don't ignore the known-bad answers, they'd >>> hopefully iterate until they get a not-known-bad key one way or >>> another. >>> >>> I think so, but maybe you're seeing something I'm not. >>> >>> Something not that clear in the -00 is that the responder here >>> can supply random bits as a side effect of answering the >>> query. (The -01 will make this clearer when its ready.) >>> >>> >>> S. >>> >>>> >>>> Adam >>>> >>>> On 16 February 2012 14:12, Stephen Farrell >>>> wrote: >>>>> >>>>> >>>>> Dunno if anyone else thinks this might be interesting >>>>> but I do:-) >>>>> >>>>> So I sketched out an initial idea for how it might fit >>>>> in here. [1] >>>>> >>>>> Comments welcome. >>>>> >>>>> S. >>>>> >>>>> [1] http://www.ietf.org/id/draft-farrell-kc-00.txt >>>>> >>>>> >>>>> On 02/15/2012 07:17 PM, Stephen Farrell wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hiya, >>>>>> >>>>>> I guess the recent publications about common factors [1,2] >>>>>> are something else that this group might want to consider. >>>>>> >>>>>> I wonder if an rsa modulus checker protocol might help or >>>>>> something. Not sure if that's something that could be run >>>>>> quickly enough though, other than for the straight >>>>>> duplicates or dumbass things with small factors you should >>>>>> spot yourself. Anyone know? >>>>>> >>>>>> Or maybe you could register your public key and get a >>>>>> nonce, then come back periodically to see if any problems >>>>>> have been detected for your key. >>>>>> >>>>>> And yes, better prngs are needed, but there'll probably >>>>>> always be bad ones out there. >>>>>> >>>>>> S. >>>>>> >>>>>> [1] http://eprint.iacr.org/2012/064 >>>>>> [2] >>>>>> >>>>>> >>>>>> http://it.slashdot.org/story/12/02/15/1540212/factorable-keys-twice-as-many-but-half-as-bad >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> therightkey mailing list >>>>>> therightkey@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/therightkey >>>>>> >>>>> _______________________________________________ >>>>> therightkey mailing list >>>>> therightkey@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/therightkey >>>> >>>> _______________________________________________ >>>> therightkey mailing list >>>> therightkey@ietf.org >>>> https://www.ietf.org/mailman/listinfo/therightkey >>>> >>> >> _______________________________________________ >> therightkey mailing list >> therightkey@ietf.org >> https://www.ietf.org/mailman/listinfo/therightkey >> > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > From mrex@sap.com Mon Feb 20 10:31:50 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861E421F8753 for ; Mon, 20 Feb 2012 10:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.876 X-Spam-Level: X-Spam-Status: No, score=-8.876 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SizCYJk9Y3LW for ; Mon, 20 Feb 2012 10:31:49 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6EC21F874A for ; Mon, 20 Feb 2012 10:31:49 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1KIVg6U013341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Feb 2012 19:31:43 +0100 (MET) From: Martin Rex Message-Id: <201202201831.q1KIVfBm019933@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Mon, 20 Feb 2012 19:31:41 +0100 (MET) In-Reply-To: from "Nico Williams" at Feb 17, 12 05:11:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: therightkey@ietf.org, hallam@gmail.com, stephen.farrell@cs.tcd.ie Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:31:50 -0000 Nico Williams wrote: > > > > 2) Is ideal but adds to hardware cost. Unless that is someone can work > > out a cheap way to get random data into a D/A port or other I/O pin. > > A floating D/A input will do. Also, CPUs can implement an RNG > relatively cheaply. Sun did it in UltraSPARC CPUs, and Intel does it > now in theirs. I believe that a purely software-based high quality seeding of a CPRNG is not that difficult, but a lot of implementations are not going a very (efficient) job here. What is randomness/entropy? It is "un-predictability". In order to create good seeds and reseeds, you have to (a) find events that can not be predicted with 100% accuracy at 100% of the time and (b) collect enough of those events and compress them without killing too much of the entropy during compression. 1 Bit of entropy for an event means that it can be predicted with 100% accuracy at most 50% of the time. 0.1 Bit of entropy for an event means that can be predicted with 100% accuracy at most 95% of the time. The "difficult" part is figuring out possible event sources, sampling, them and making a very conservative assessment about the actual amount of randomness in an event (or more precisely in the delta between two events of the same type). In order to create a seed with an estimated 128 Bits of entropy for your CPRNG entropy pool, you would collect at least 1280 0.1-Bit events or 128 1-Bit events, put them into an array and use a cryptographic hash as a compression function, preferably a hash with 2x larger output size than the amount of assumed combined entropy/randomess in the collected events. In typical PCs, workstations & servers you find plenty of "events" that can be used. It may be more difficult for embedded devices, where there is *much* less concurrency inside the device itself. But as soon as there is some hardware media attached to such a device (LAN or WLAN), or a harddisk with physical platters, there should be an event source available, and if the hardware supports any high resolution counter (a millisecond or better), such events can be sampled. An IMHO poor source of entropy is a mouse moved by a human user. It's actually confusing to see how popular mouse-moves seem to be for by key-generation programs for PCs, where *MUCH* better sources of randomness are available that can collect at least as good entropy without bothering the user. -Martin From mrex@sap.com Mon Feb 20 12:04:12 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A2821F8598 for ; Mon, 20 Feb 2012 12:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.073 X-Spam-Level: X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qafzM49UeI0G for ; Mon, 20 Feb 2012 12:04:11 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E1D9C21F8594 for ; Mon, 20 Feb 2012 12:04:10 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1KK409R029121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Feb 2012 21:04:05 +0100 (MET) From: Martin Rex Message-Id: <201202202003.q1KK3xtn025164@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Mon, 20 Feb 2012 21:03:59 +0100 (MET) In-Reply-To: from "Nico Williams" at Feb 17, 12 02:37:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: therightkey@ietf.org, hallam@gmail.com, stephen.farrell@cs.tcd.ie Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:04:12 -0000 Nico Williams wrote: > > Phillip Hallam-Baker wrote: > > > > It would be really nice if there was some way to audit > > RNGs algorithmically... > > Separate the HW RNG and other entropy gathering parts from the rest of > the RNG (i.e., the entropy pool, the mixer, the extractor), and you > provide a per-device seed for testing. Correct. You can and should test the entropy _inputs_ whether they meet your assumption of "unpredictability". Testing the output of the CPRNG is of limited value (it would only ring bells if both, the randomness in the entropy inputs are way behind their assumed properties, plus there is a serious problem in your CPRNG in moving from state n to state n+1). > > But you have to make sure that > any test modes can't be enabled without tampering with the physical > device. Once the device is sealed you should not be able to test the > RNG in any way other than by statistical analysis of its outputs. This rings my "snake-oil" alarm bells. If your assessments of the entropy of your inputs is correct, then there will NOT be a problem to offer the test mode when the device is in use. You just need to ensure that the test mode reveals only surplus samples that your CPRNG does not use. Most devices should be able to produce much more samples that what is needed/consumed by the CPRNG, and there should not be a problem _per_se_ by allowing the testing of samples when the device is in productive use. Not revealing anything may result in the *real* randomness being stronger than the conservative assessment from the design. But you should be using a sufficient safety margin ( factor >= 2 ) in assessing the effective randomness of your input parameters anyway. And letting unauthenticated peers pull entropy input samples is probably always a bad idea. -Martin From hallam@gmail.com Mon Feb 20 12:46:17 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2035D21F8618 for ; Mon, 20 Feb 2012 12:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQk8jbWmuAYr for ; Mon, 20 Feb 2012 12:46:16 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D4C7E21F85F8 for ; Mon, 20 Feb 2012 12:46:15 -0800 (PST) Received: by obbwd15 with SMTP id wd15so8805677obb.31 for ; Mon, 20 Feb 2012 12:46:15 -0800 (PST) Received-SPF: pass (google.com: domain of hallam@gmail.com designates 10.60.12.231 as permitted sender) client-ip=10.60.12.231; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hallam@gmail.com designates 10.60.12.231 as permitted sender) smtp.mail=hallam@gmail.com; dkim=pass header.i=hallam@gmail.com Received: from mr.google.com ([10.60.12.231]) by 10.60.12.231 with SMTP id b7mr10734930oec.38.1329770775514 (num_hops = 1); Mon, 20 Feb 2012 12:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lNeNQ5j9thWczAT5zgKQ4snajHojO2+c1DQWGeepGYo=; b=fXnl7yeX8XBbvQlNtKP/PXCo3e3wjAddyzeo9QkbrYiXHloRptjJEBLd5WYkEpUxcJ 7bjva4CslHsts+9NECZvljKsv/MSUdidzwzZGVMdCrzAaID0B/7Yl3hD5ERPLMjEgbNM AAFUmNq0whv9QtmIf7sC1H0kU4wkldEPjUHBU= MIME-Version: 1.0 Received: by 10.60.12.231 with SMTP id b7mr9215454oec.38.1329770775458; Mon, 20 Feb 2012 12:46:15 -0800 (PST) Received: by 10.182.38.97 with HTTP; Mon, 20 Feb 2012 12:46:15 -0800 (PST) In-Reply-To: <201202202003.q1KK3xtn025164@fs4113.wdf.sap.corp> References: <201202202003.q1KK3xtn025164@fs4113.wdf.sap.corp> Date: Mon, 20 Feb 2012 15:46:15 -0500 Message-ID: From: Phillip Hallam-Baker To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nico Williams , therightkey@ietf.org, stephen.farrell@cs.tcd.ie Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 20:46:17 -0000 Stephen's protocol would address one particular type of PRNG screw up, the case where the PRNG is so badly screwed up that duplicate keys are seen. A more common screw up is the Netscape bug where the PRNG has a sound algorithm but is working on too little initial entropy (about 30 bits I seem to recall). In the Netscape case the only way to fix the problem was to reverse engineer the code. After conversations with Jeff Schiller, Alan Schiffman and others I had a long conversation with Marc Andressen on the design of the PRNG in the early editions of Navigator. This was after I broke SSL 1.0 in ten mins and he wasn't too keen talking to me. Eventually I managed to convince them that putting 30 bits worth of entropy through MD5 would not produce 128 bits of randomness. Marc then did something he should have done at the start and they finally hired some real crypto people (Taher & the bros Wienstein). They also asked me how to do the job right so I sent the design notes for the code in Shen. A year later the PRNG bug was rediscovered. I asked what had happened and the response I got back was that they had looked at the design notes for the PRNG and they were so comprehensive they didn't feel the need to check the code. So the moral I draw from that is that where the PRNG is concerned there really is no substitute for checking the code where public key algorithms are concerned. This is not the case for symmetric algorithms where it is sufficient for either side to introduce a sufficient amount of entropy. On Mon, Feb 20, 2012 at 3:03 PM, Martin Rex wrote: > Nico Williams wrote: >> >> Phillip Hallam-Baker wrote: >> > >> > It would be really nice if there was some way to audit >> > RNGs algorithmically... >> >> Separate the HW RNG and other entropy gathering parts from the rest of >> the RNG (i.e., the entropy pool, the mixer, the extractor), and you >> provide a per-device seed for testing. > > Correct. =A0You can and should test the entropy _inputs_ whether they > meet your assumption of "unpredictability". =A0Testing the output > of the CPRNG is of limited value (it would only ring bells if both, > the randomness in the entropy inputs are way behind their assumed > properties, plus there is a serious problem in your CPRNG in > moving from state n to state n+1). > > >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 But you have to make sure that >> any test modes can't be enabled without tampering with the physical >> device. =A0Once the device is sealed you should not be able to test the >> RNG in any way other than by statistical analysis of its outputs. > > This rings my "snake-oil" alarm bells. > > If your assessments of the entropy of your inputs is correct, then > there will NOT be a problem to offer the test mode when the device > is in use. =A0You just need to ensure that the test mode reveals only > surplus samples that your CPRNG does not use. > Most devices should be able to produce much more samples that what > is needed/consumed by the CPRNG, and there should not be a problem > _per_se_ by allowing the testing of samples when the device is in > productive use. > > Not revealing anything may result in the *real* randomness being stronger > than the conservative assessment from the design. =A0But you should be > using a sufficient safety margin ( factor >=3D 2 ) in assessing the effec= tive > randomness of your input parameters anyway. =A0And letting unauthenticate= d > peers pull entropy input samples is probably always a bad idea. > > > -Martin --=20 Website: http://hallambaker.com/ From stephen.farrell@cs.tcd.ie Mon Feb 20 13:13:00 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1632021F8705 for ; Mon, 20 Feb 2012 13:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mc2YUmbJ+8c9 for ; Mon, 20 Feb 2012 13:12:38 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 03C6421F8618 for ; Mon, 20 Feb 2012 13:12:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 63C8F171D0A; Mon, 20 Feb 2012 21:12:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1329772354; bh=e80Iqf+NfYbu+l 9LsLhjxOL2kn1sQOjfUzq68qS56kw=; b=gBrW3b34JBSNLL80UmpZ5twU62VDmT eQvYRrDWNhrJ1DBC8sixZFpttea1miZhqncGSuzSlpP2OI5IUHhsOeX3X1Y04955 xRP2GtruxZb1qqs9IIHOcVodzLJdyz5F8tV4+zXUKe8EGB8NDU5rTIybGgfOGAXI wA+WGAyUJUgHaPnhDK+XOkVjvlRhIGQR732I8RLxK/FA8hLnFOnv8+623MqK628U z+P48/9h/ntrMqwYGx6Bl1GNh2FG3v0PjFu5NZZYOpXSvtnDvGz8KR4hT7y553aQ 1WeuVOCVblkHEL1N6Ybza7V7g6cYpKiIQK4fEyojQRsOEk5wtQvfQmnQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id S3bnK7ZCkX6D; Mon, 20 Feb 2012 21:12:34 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.42.186.251]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6A677171D01; Mon, 20 Feb 2012 21:12:34 +0000 (GMT) Message-ID: <4F42B741.6020006@cs.tcd.ie> Date: Mon, 20 Feb 2012 21:12:33 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <201202202003.q1KK3xtn025164@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: therightkey@ietf.org Subject: Re: [therightkey] common factors X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 21:13:00 -0000 On 02/20/2012 08:46 PM, Phillip Hallam-Baker wrote: > Stephen's protocol would address one particular type of PRNG screw up, > the case where the PRNG is so badly screwed up that duplicate keys are > seen. Well, anything detectable from the public key (and a signature I guess, hard to see what that might be but who knows). So both the common factors thing and e.g. the blacklisted keys from the earlier debian problems could be detected. I guess really stupid lengths could be barfed on too and even even RSA moduli. (I know, these should ever happen, but...) Point is that a protocol can help with (some) new types of problem too as we discover that those problem kinds of key have gotten out there and been discovered. Its an open question as to whether this is worthwhile, (e.g. maybe nobody would offer such a service) but I think it'd be good to have it (properly) spec'd in case it does turn out to be useful. (I'd be glad to get more review to get "properly" bit sorted btw - I'm bound to have done something dumb:-) S. PS: I do entirely agree about fixing implementations as well but am just focusing on another aspect myself. > > A more common screw up is the Netscape bug where the PRNG has a sound > algorithm but is working on too little initial entropy (about 30 bits > I seem to recall). > > In the Netscape case the only way to fix the problem was to reverse > engineer the code. After conversations with Jeff Schiller, Alan > Schiffman and others I had a long conversation with Marc Andressen on > the design of the PRNG in the early editions of Navigator. This was > after I broke SSL 1.0 in ten mins and he wasn't too keen talking to > me. Eventually I managed to convince them that putting 30 bits worth > of entropy through MD5 would not produce 128 bits of randomness. > > Marc then did something he should have done at the start and they > finally hired some real crypto people (Taher& the bros Wienstein). > They also asked me how to do the job right so I sent the design notes > for the code in Shen. > > A year later the PRNG bug was rediscovered. I asked what had happened > and the response I got back was that they had looked at the design > notes for the PRNG and they were so comprehensive they didn't feel the > need to check the code. > > > So the moral I draw from that is that where the PRNG is concerned > there really is no substitute for checking the code where public key > algorithms are concerned. > > This is not the case for symmetric algorithms where it is sufficient > for either side to introduce a sufficient amount of entropy. > > On Mon, Feb 20, 2012 at 3:03 PM, Martin Rex wrote: >> Nico Williams wrote: >>> >>> Phillip Hallam-Baker wrote: >>>> >>>> It would be really nice if there was some way to audit >>>> RNGs algorithmically... >>> >>> Separate the HW RNG and other entropy gathering parts from the rest of >>> the RNG (i.e., the entropy pool, the mixer, the extractor), and you >>> provide a per-device seed for testing. >> >> Correct. You can and should test the entropy _inputs_ whether they >> meet your assumption of "unpredictability". Testing the output >> of the CPRNG is of limited value (it would only ring bells if both, >> the randomness in the entropy inputs are way behind their assumed >> properties, plus there is a serious problem in your CPRNG in >> moving from state n to state n+1). >> >> >>> >>> But you have to make sure that >>> any test modes can't be enabled without tampering with the physical >>> device. Once the device is sealed you should not be able to test the >>> RNG in any way other than by statistical analysis of its outputs. >> >> This rings my "snake-oil" alarm bells. >> >> If your assessments of the entropy of your inputs is correct, then >> there will NOT be a problem to offer the test mode when the device >> is in use. You just need to ensure that the test mode reveals only >> surplus samples that your CPRNG does not use. >> Most devices should be able to produce much more samples that what >> is needed/consumed by the CPRNG, and there should not be a problem >> _per_se_ by allowing the testing of samples when the device is in >> productive use. >> >> Not revealing anything may result in the *real* randomness being stronger >> than the conservative assessment from the design. But you should be >> using a sufficient safety margin ( factor>= 2 ) in assessing the effective >> randomness of your input parameters anyway. And letting unauthenticated >> peers pull entropy input samples is probably always a bad idea. >> >> >> -Martin > > > From kent@bbn.com Tue Feb 21 10:08:00 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A170821F87EE for ; Tue, 21 Feb 2012 10:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.108 X-Spam-Level: X-Spam-Status: No, score=-105.108 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGgSMVg2qS5c for ; Tue, 21 Feb 2012 10:08:00 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2476E21F87AA for ; Tue, 21 Feb 2012 10:08:00 -0800 (PST) Received: from [192.1.255.155] (port=49186) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rzu85-000HmL-Ua; Tue, 21 Feb 2012 13:07:58 -0500 Mime-Version: 1.0 Message-Id: Date: Tue, 21 Feb 2012 12:49:34 -0500 To: aerowolf@gmail.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: therightkey@ietfa.amsl.com Subject: [therightkey] principle of least privilege X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 18:08:00 -0000 Kyle, In a previous message you said "...Trying to insist that the DN be matched solely from an authoritative CA violates this "principle of least privilege", which means that people can't use authoritative CAs if they want to protect their personal information from identity thieves and still communicate over the network." PoLP is very well aligned with the model of authoritative CAs, since each CA is trusted only for the scope of identity info for which it is authoritative. If I have a gmail account for MrBig, then if Google issues a cert identifying me as MrBig@gmail.com I can have privacy (well, maybe not so much as before the new Google policies ;-)) and still be consistent with the authoritative CA model. Steve From kaie@kuix.de Thu Feb 23 11:55:23 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2745721F8618 for ; Thu, 23 Feb 2012 11:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2tAoJifxL0O for ; Thu, 23 Feb 2012 11:55:22 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [82.165.38.173]) by ietfa.amsl.com (Postfix) with ESMTP id EE6CC21F852E for ; Thu, 23 Feb 2012 11:55:21 -0800 (PST) Received: from [192.168.2.253] (p4FF341D6.dip.t-dialin.net [79.243.65.214]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id D984840000A3 for ; Thu, 23 Feb 2012 20:55:19 +0100 (CET) Message-ID: <4F4699A7.1000106@kuix.de> Date: Thu, 23 Feb 2012 20:55:19 +0100 From: Kai Engert User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: "therightkey@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [therightkey] Combining OCSP stapling with advance MITM preparation X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 19:55:23 -0000 I've just sent the following message to Mozilla's dev-tech-crypto mailing list, and I thought you might be interested, too. While working on an updated paper of the MECAI proposal (which I hope to post in the next couple of days), the following orthogonal idea came to me. I don't know whether it is a new idea, or whether it has been discussed/mentioned before. Let's say the owner of a domain learns that a rogue certificate for their domain has been issued, and is being controlled by an attacker. (For example because of a user's report, who used any of the systems that may help to detect a rogue certificate.) The rogue certificate will be revoked, but because of today's reality of incomplete revocation checking, the victim might be unable to perform revocation checking and still be attackable. The following idea only helps against those attackers who can only temporarily control act as a MITM, who only temporary control the network connection between a client and a server, such as users with mobile devices, and may only help with sites that are visited frequently by the user. As soon as the certificate has been revoked, the domain owner is able to obtain an OCSP response for the rogue certificate. The domain owner could configure their server to include this OCSP response in all TLS handshakes, even though this OCSP response is unrelated to the server certificate actually being used. If clients had a persistent OCSP cache, in particular bundled with a persistent OCSP cache for all revocation events, then users/clients could potentially learn about important revoked certificates in advance, for the servers they frequently visit. I believe this is an argument for getting OCSP stapling (and in particular "multi OCSP stapling" as proposed by Yngve Pettersen) implemented and widely deployed more quickly. Actually, here is an expansion of this idea, not sure if it is practial. We could invent a new communication protocol between servers and CA's OCSP servers. Servers could be allowed to contact (daily) each of the publicly known CAs. The server could ask "do you know about any revoked certificates for my server's hostname?". Assuming the CA has a database of their incorrectly issued certificates, it could lookup the affected certificates, produce a revocation OCSP response for each of them, and send them back to the server. This way, information about compromised certificates could be distributed automatically, only between the parties that are really interested in such certificates. Of couse, this "advance OCSP stapling" doesn't help if the user connects to the system for the first time, or visits the system infrequently and therefore doesn't have a chance to learn about the rogue certificate early. That's where MECAI might be able to help. Kai From nico@cryptonector.com Thu Feb 23 12:10:33 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7D821F8866 for ; Thu, 23 Feb 2012 12:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph1zmT-8LWmL for ; Thu, 23 Feb 2012 12:10:26 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id A358C21F8857 for ; Thu, 23 Feb 2012 12:10:26 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 6ACFE678063 for ; Thu, 23 Feb 2012 12:10:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=yghTcZRoTSAj7T3oZlN8s PJ27/CSFQNDjNImXZBxnsudRHPogya1ZC7TjTJaEZHVH/tDbMUzx1cLkQacPX5Qd X0Srvu2nRkblm+g4H+c15VPUZv7kTNE7RET2S4eKjhmvXeQbLJthLlCkcF07oh/6 gicf8BfMXqgffxr54zzEXw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=XDrSJZPFNz5clgDpGFxF iEgKDEY=; b=HB1emzidn3JgdrdesfeLyrscGyfR9JlqG1OAGBDGT6gDxu1rUWl5 Ca/5r0te5Bic3Bn1eIwG//DySGSjO15aebN2SDIOaISJKsAHPpoGAgOkssbuu2HR maZjSYtxhGoSY5X/ZS9KDq+m5+kq7BYympNvnoiBctaD9dMjhyQuuC4= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 51472678058 for ; Thu, 23 Feb 2012 12:10:26 -0800 (PST) Received: by dakl33 with SMTP id l33so1706029dak.31 for ; Thu, 23 Feb 2012 12:10:24 -0800 (PST) Received-SPF: pass (google.com: domain of nico@cryptonector.com designates 10.68.228.69 as permitted sender) client-ip=10.68.228.69; Authentication-Results: mr.google.com; spf=pass (google.com: domain of nico@cryptonector.com designates 10.68.228.69 as permitted sender) smtp.mail=nico@cryptonector.com Received: from mr.google.com ([10.68.228.69]) by 10.68.228.69 with SMTP id sg5mr8243353pbc.118.1330027824727 (num_hops = 1); Thu, 23 Feb 2012 12:10:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.228.69 with SMTP id sg5mr6745302pbc.118.1330027824707; Thu, 23 Feb 2012 12:10:24 -0800 (PST) Received: by 10.68.28.6 with HTTP; Thu, 23 Feb 2012 12:10:24 -0800 (PST) In-Reply-To: <4F4699A7.1000106@kuix.de> References: <4F4699A7.1000106@kuix.de> Date: Thu, 23 Feb 2012 14:10:24 -0600 Message-ID: From: Nico Williams To: Kai Engert Content-Type: text/plain; charset=UTF-8 Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Combining OCSP stapling with advance MITM preparation X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 20:10:33 -0000 Google's solution is to push CRLs directly to the client (well, the client pulls CRL updates, but you get the point): http://www.imperialviolet.org/2012/02/05/crlsets.html I agree that a combination of OCSP Response stapling plus pinning of the fact that the server does OCSP Response stapling would be nice. That's not quite what you propose. But in any case, it seems that it's getting late for OCSP to come to the rescue, though I really hope not. IMO OCSP always wanted to be stapled. Nico -- From stephen.farrell@cs.tcd.ie Thu Feb 23 13:37:54 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB35721F88AF for ; Thu, 23 Feb 2012 13:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSi+EyolfuNm for ; Thu, 23 Feb 2012 13:37:54 -0800 (PST) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 0468F21F888F for ; Thu, 23 Feb 2012 13:37:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EBDB9171CC8 for ; Thu, 23 Feb 2012 21:37:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1330033072; bh=ATLav0Tv6PnN5D gRyKAqymkaCH3Pg45SYj8e9/BpfCQ=; b=pNftl7fsnw/XSoIS86kC2t2uMfmZGq C7c7mPTnygTJp+e1iYXZVlXTlneHJPvDMQ4LugBmI5kOTCTwSqhhKmzfP+lYmHbi gWokMdiMny4Bz9hkn8xapjunhia5iqSfCuiBDjFrg3MvJL6MvYiDYuQmq5o99WfI bGvwWdVeqxf2DDNBcy1Y1YcPrgeOt4XwmPrEf9dj6iFPlV4SVme9tbfaZ35Ef6Us 8LdYilU17viZ8z66jLuVxqPTW9dTwRJHCztDHY225VaDyl0JcXuC6BTx26apaJDJ mLU5GCKvjPnQeTKiuPuhT3tBKGVSd1HrJf/VlM7k4HquBfBIXmyTAeEg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ozcGwqixS5-Z for ; Thu, 23 Feb 2012 21:37:52 +0000 (GMT) Received: from [10.87.48.4] (unknown [86.45.59.230]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 912CF171CBC for ; Thu, 23 Feb 2012 21:37:52 +0000 (GMT) Message-ID: <4F46B1B0.2020809@cs.tcd.ie> Date: Thu, 23 Feb 2012 21:37:52 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "therightkey@ietf.org" References: <20120223213019.7A48621F87A2@ietfa.amsl.com> In-Reply-To: <20120223213019.7A48621F87A2@ietfa.amsl.com> X-Forwarded-Message-Id: <20120223213019.7A48621F87A2@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [therightkey] Fwd: 83rd IETF DRAFT Agenda X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 21:37:54 -0000 The draft agenda for Paris is out, so arranging a time to get together that fits with that should be easier now. Note though that the IETF agenda can still change, but probably won't change by that much. (In particular since this meeting is fairly tight on slots.) Please also note that if you are meeting then we may not be able to organise a meeting room in the evening in this venue (not sure yet.) That'd likely force folks into a real bar or restaurant. But then that's good:-) S -------- Original Message -------- Subject: 83rd IETF DRAFT Agenda Date: Thu, 23 Feb 2012 13:30:19 -0800 (PST) From: IETF Agenda To: Working Group Chairs CC: irsg@irtf.org The DRAFT agenda is ready for viewing. Please note the cutoff date for requests to reschedule Working Group and BOF meetings is February 27, 2012 17:00 PT. The final agenda will be published on March 2, 2012. https://datatracker.ietf.org/meeting/83/agenda.html https://datatracker.ietf.org/meeting/83/agenda.txt http://www.ietf.org/meeting/83/index.html Thanks, Wanda Only 30 days until Paris, 83rd IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meeting/register.html From kaie@kuix.de Thu Feb 23 17:10:37 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7E411E8097 for ; Thu, 23 Feb 2012 17:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvgCC8d7nW3E for ; Thu, 23 Feb 2012 17:10:36 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [82.165.38.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8528211E808A for ; Thu, 23 Feb 2012 17:10:26 -0800 (PST) Received: from [192.168.2.116] (p4FF341D6.dip.t-dialin.net [79.243.65.214]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id 83F094000088 for ; Fri, 24 Feb 2012 02:10:25 +0100 (CET) Message-ID: <4F46E380.1000703@kuix.de> Date: Fri, 24 Feb 2012 02:10:24 +0100 From: Kai Engert User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: "therightkey@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [therightkey] MECAI proposal - Version 2 X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 01:10:37 -0000 Please find a more detailed description of my proposal MECAI - Mutually Endorsing CA Infrastructure at https://kuix.de/mecai/mecai-proposal-v2.pdf (PDF, 12 pages) I'm looking forward to your feedback, please let me know if parts are difficult to understand or need clarification. Best Regards, Kai PS: The page below also has a link to an html version of the document, but the layout created by LibreOffice isn't very beautiful: https://kuix.de/mecai/ From kaie@kuix.de Sat Feb 25 09:22:31 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0768421F8598 for ; Sat, 25 Feb 2012 09:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbqcOycAMtio for ; Sat, 25 Feb 2012 09:22:30 -0800 (PST) Received: from s15531995.onlinehome-server.info (s15531995.onlinehome-server.info [82.165.38.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3496C21F8592 for ; Sat, 25 Feb 2012 09:22:29 -0800 (PST) Received: from [192.168.2.116] (p4FF35EB5.dip.t-dialin.net [79.243.94.181]) by s15531995.onlinehome-server.info (Postfix) with ESMTPSA id AE4564003B83; Sat, 25 Feb 2012 18:22:26 +0100 (CET) Message-ID: <4F4918D2.4040907@kuix.de> Date: Sat, 25 Feb 2012 18:22:26 +0100 From: Kai Engert User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Nico Williams References: <4F4699A7.1000106@kuix.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "therightkey@ietf.org" Subject: Re: [therightkey] Combining OCSP stapling with advance MITM preparation X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 17:22:31 -0000 On 23.02.2012 21:10, Nico Williams wrote: > Google's solution is to push CRLs directly to the client (well, the > client pulls CRL updates, but you get the point): > http://www.imperialviolet.org/2012/02/05/crlsets.html If my understanding is correct that they are pushing only a subset, then there is the risk that important revocations are filtered. Any revocation event might be important. If a trainee at a CA issues a test cert for www.important.site, then immediately revokes it, who decides whether that should be filtered or not? Kai From Jeff.Hodges@KingsMountain.com Wed Feb 29 08:25:46 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DF421F8710 for ; Wed, 29 Feb 2012 08:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbcxuEGu9-oV for ; Wed, 29 Feb 2012 08:25:45 -0800 (PST) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 5BFAF21F8630 for ; Wed, 29 Feb 2012 08:25:45 -0800 (PST) Received: (qmail 31056 invoked by uid 0); 29 Feb 2012 16:25:45 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 29 Feb 2012 16:25:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=RejCJzV1gFIPu22+BVgudAON7F0vI4XiNxx1J73+g1o=; b=3XFQ32de34nuxuUblmIjgf5dvZX6bJKH0GREuCeU51S+MEeM5lsvJQ/NK6wAondaAj8X2ZmtOCJwJIjI49Xb9EtpNYhyk8bqUWI6zXJALmzyyIERL+CaGxytwKWjTiIR; Received: from [67.218.125.10] (helo=[172.18.54.103]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1S2mLX-00058Z-3a for therightkey@ietf.org; Wed, 29 Feb 2012 09:25:43 -0700 Message-ID: <4F4E5183.8040702@KingsMountain.com> Date: Wed, 29 Feb 2012 08:25:39 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 67.218.125.10 authed with jeff.hodges+kingsmountain.com} Subject: [therightkey] fyi: CA/Browser Forum Announces Organizational Reform Working Group X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 16:25:46 -0000 Of possible interest (note the solicitation of position papers and statements of interest down at the end; Also, this has already been posted to tls@ietf.org and saag@ietf.org)... --- http://cabforum.org/org_announcement.html 28 February 2012 CA/Browser Forum Announces Organizational Reform Working Group The CA/Browser Forum is a voluntary organization of leading certification authorities (CAs) and vendors of Internet browser software and other applications. At the twenty fifth face to face meeting of the CA/Browser Forum, held in Santa Clara, California, USA on February 22 and 23rd, 2012, the membership agreed to form a working group on organizational reform. The task of this group will be to develop and present to the full organization, by April 16th, proposals for a new charter and bylaws. The CA/Browser Forum recognizes the growing importance of the PKI marketplace as a critical piece of Internet infrastructure, and the need to continue to safeguard and advance the public's trust in the Internet as a secure place for communication, socialization and commerce. The goal of the reform will be to evolve the organization into a more mature and capable, multi-stakeholder forum that can promote the growth and maintenance of the public PKI and certificate ecosystem in the interests of Internet security and the broader public good. Key topics to be addressed by the special working group include: Formal incorporation of the Forum; A broader scope of action; Wider membership and participation in the Forum, including by certificate subscribers, relying parties, and users; and A more open and public process. In support of this process, the special working group is soliciting short (no more than 750 words, please) position papers and statements of interest from organizations and individuals on these topics. We encourage stakeholders to submit their comments to questions@cabforum.org now through March 30, 2012. All submissions will be posted publicly on the CA/Browser Forum website. (www.cabforum.org) --- end From Jeff.Hodges@KingsMountain.com Wed Feb 29 15:55:48 2012 Return-Path: X-Original-To: therightkey@ietfa.amsl.com Delivered-To: therightkey@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC5521F84EC for ; Wed, 29 Feb 2012 15:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.102 X-Spam-Level: X-Spam-Status: No, score=-100.102 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoP1gnggRKQo for ; Wed, 29 Feb 2012 15:55:47 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 4C6D221F8783 for ; Wed, 29 Feb 2012 15:55:47 -0800 (PST) Received: (qmail 5033 invoked by uid 0); 29 Feb 2012 23:55:46 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 29 Feb 2012 23:55:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=su4RNKBRWp5pHm8hTEvlUSL7UEegxBXTc9Ttbr/7q4s=; b=aNSUuzjLD0OfuUYLMcUcVqTGNjQhF5u4FovnKmB4w8XiFoe6IJLurX2OSqaZJDzzXV0K604iAIusmTniS38fliOIodhQPtVz69OvjwCrR4b20NaceKi1CQFc1nwE1y7I; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1S2tN3-0001ke-G2 for therightkey@ietf.org; Wed, 29 Feb 2012 16:55:45 -0700 Message-ID: <4F4EBB00.30808@KingsMountain.com> Date: Wed, 29 Feb 2012 15:55:44 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: therightkey@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [therightkey] fyi: CA/Browser Forum Announces Organizational Reform Working Group X-BeenThere: therightkey@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 23:55:48 -0000 Here's PayPal's public position statement we submitted to the CA/Browser Forum reform working group.. PayPal supports reform at the CA/Browser Forum =JeffH Internet Standards and Governance Team PayPal Information Risk Management