Re: [pkng] Where to go? What to do?
Rene Struik <rstruik.ext@gmail.com> Thu, 30 September 2010 14:47 UTC
Return-Path: <rstruik.ext@gmail.com>
X-Original-To: pkng@core3.amsl.com
Delivered-To: pkng@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4EF43A6B8E for <pkng@core3.amsl.com>; Thu, 30 Sep 2010 07:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.139
X-Spam-Level:
X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN8HSN0qvy-t for <pkng@core3.amsl.com>; Thu, 30 Sep 2010 07:47:12 -0700 (PDT)
Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by core3.amsl.com (Postfix) with ESMTP id 314C63A6918 for <pkng@irtf.org>; Thu, 30 Sep 2010 07:47:12 -0700 (PDT)
Received: by ywt2 with SMTP id 2so840991ywt.13 for <pkng@irtf.org>; Thu, 30 Sep 2010 07:47:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=3RID0ojdPHrKSTrpBah0uPkCkoz6FugXHQwpuzDKJIg=; b=tvaYsCwagqhXu8ynaDL9p4RmUCOYvLAgkPllArMUPm2QeE39KJTid8Hr19UmQ/0+uy RnJhbtjRAHBdjTcVVATzWFG3L9dcO8/Bb5k5vFC43PiRy2hInVC9uwyyM6JL7KVHxc+g W48g0bmS+VSbwhRm9A943GorIb3vrZMcf0XM8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=fN2fN9nTokF+3Ihfg0aPxULcDVncmEVOPWuZ+rRYMIRMj03ae9uu9Aap6YULiEZBrn JRLpM2R1zjhtd3vNbmqfMOe9TSD9BaRrfwUgIVjwWGZ8p/WP6iiXOYHRPXZC7nTAGOkR pDqRyRhRwK2DI0sg7UGLIDA/Wz9evfOHty47U=
Received: by 10.231.185.142 with SMTP id co14mr2722587ibb.97.1285858077459; Thu, 30 Sep 2010 07:47:57 -0700 (PDT)
Received: from [192.168.1.103] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.232.69.160]) by mx.google.com with ESMTPS id h8sm10330584ibk.21.2010.09.30.07.47.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Sep 2010 07:47:55 -0700 (PDT)
Message-ID: <4CA4A316.9040805@gmail.com>
Date: Thu, 30 Sep 2010 10:47:50 -0400
From: Rene Struik <rstruik.ext@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <p06240825c8c7fd5ca338@[10.20.30.163]>
In-Reply-To: <p06240825c8c7fd5ca338@[10.20.30.163]>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: pkng@irtf.org
Subject: Re: [pkng] Where to go? What to do?
X-BeenThere: pkng@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Public Key Next Generation \(PKNG\) Research Group" <pkng.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/pkng>, <mailto:pkng-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/pkng>
List-Post: <mailto:pkng@irtf.org>
List-Help: <mailto:pkng-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pkng>, <mailto:pkng-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2010 14:47:13 -0000
Hi Paul: For constrained environments where one wishes to introduce device certificates (think: "internet of things"), I can imagine the following topics to be of interest: 1) easier way to enrol a device (RA function), where one does not always have the burden of providing proof of possession prior to registering a public key generated on a device (an (example would be scenarios where one would enrol a billion devices during chip testing); 2) getting rid of CRL issues (the kiss of death in sleepy networks --- and perhaps in more general networks, since if taken literally and doing online certificate revocation checks all the time, one might as well almost go to a centralized Kerberos-style key management approach) and enabling short-lived certs for smart object-type environments; 3) seriously shrinking down the size of certificates (at loss of some combinatorial freedom, but freedom almost never fully invoked in practical policy environment); 4) catering to less certificate chaining - in constrained networks, such as process control networks and smart grid type environments, one can easily envision certificate chains of length two (or even length one, since the parent CA only very slowly changes over time or not at all); 5) tacking issues of race to the bottom with proliferation of hundreds of CAs in everyone's web browser. How is one to be sure that one cannot shop around and get a cert from a half-sleeping CA, which used to have stellar reputation and policies, but is now up for grabs? ("quis custodiet custodes?") 6) striving for removal of the computational burden of certificate checks on client device, so that using the pretext of "proper checks are too expensive" to allow unilatreral authentication in client/server key agreement settings will loose ground to doing mutual authentication instead. Surely, this list is not exhaustive, but was just inspired by my own experience in trying to get public-key based techniques deployed with constrained, senspor-type networks. Please let me know whether this is within scope of the PKNG group. Best regards, Rene Best regards, Rene On 28/09/2010 4:22 PM, Paul Hoffman wrote: > Greetings again. This list has not been used to good measure yet, and it is not clear if it will be. This would be a good time to find out. > > This RG has a charter that was well-discussed; it is at<http://irtf.org/charter?gtype=rg&group=pkng>. In particular: > > The research challenges expected to be faced by the PKNG RG include devising a taxonomy for PKI that is based on maximal utility for a wide variety of users; avoiding features whose genesis derive from the semantics of PKIX rather than the general use cases for public keys; issues of privacy and identification in certificates; and determining how to evaluate differences in transition strategies given that such a transition has never taken place on the Internet. The IRTF is more amenable to this type of research than, say, the IETF, where a single "requirements document" would be expected to be finished in a short period of time and a single protocol would be expected to emerge by group consensus. > > This list has had short bursts of interest in what was called "inside-out PKI", namely one that was designed with the user explicitly making all choice of trust anchors and what those anchors could attest to. However, those threads quickly languished. I think this is a ripe area for research, but only if there is interest from at least a handful of folks. > > Please speak up soon if you think that there is interesting work in our charter, and hopefully start threads here with such discussions. If we don't have sufficient interest, we can close the list quietly. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > pkng mailing list > pkng@irtf.org > https://www.irtf.org/mailman/listinfo/pkng -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363
- [pkng] Where to go? What to do? Paul Hoffman
- Re: [pkng] Where to go? What to do? Stephen Farrell
- Re: [pkng] Where to go? What to do? Rene Struik
- Re: [pkng] Where to go? What to do? Massimiliano Pala
- Re: [pkng] Where to go? What to do? Massimiliano Pala
- Re: [pkng] Where to go? What to do? Daniel Kahn Gillmor
- Re: [pkng] Where to go? What to do? Massimiliano Pala
- Re: [pkng] Where to go? What to do? Massimiliano Pala
- Re: [pkng] Where to go? What to do? Daniel Kahn Gillmor