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