Re: [pkng] Where to go? What to do?

Massimiliano Pala <Massimiliano.Pala@Dartmouth.edu> Fri, 01 October 2010 20:05 UTC

Return-Path: <Massimiliano.Pala@Dartmouth.edu>
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 325953A6D5A for <pkng@core3.amsl.com>; Fri, 1 Oct 2010 13:05:06 -0700 (PDT)
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, RCVD_IN_DNSWL_MED=-4]
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 jwn8DYWB+e1f for <pkng@core3.amsl.com>; Fri, 1 Oct 2010 13:05:04 -0700 (PDT)
Received: from mailhub2.dartmouth.edu (mailhub2.dartmouth.edu [129.170.17.107]) by core3.amsl.com (Postfix) with ESMTP id D7E123A6E06 for <pkng@irtf.org>; Fri, 1 Oct 2010 13:05:03 -0700 (PDT)
Received: from newblitzen.Dartmouth.EDU (newblitzen.Dartmouth.EDU [129.170.208.36]) by mailhub2.dartmouth.edu (8.13.5/DND2.0/8.13.5) with ESMTP id o91Jo1C2027528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <pkng@irtf.org>; Fri, 1 Oct 2010 16:04:33 -0400
X-Disclaimer: This message was received from outside Dartmouth's BlitzMail system.
Received: from dhcp-212-226.cs.dartmouth.edu [129.170.212.226] by newblitzen.Dartmouth.EDU (Mac) via SMTP for pkng@irtf.org id <177894348>; 01 Oct 2010 16:04:33 -0400
Message-ID: <4CA63F67.4010101@Dartmouth.edu>
Date: Fri, 01 Oct 2010 16:07:03 -0400
From: Massimiliano Pala <Massimiliano.Pala@Dartmouth.edu>
Organization: Dartmouth College / OpenCA Labs
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.7
MIME-Version: 1.0
To: pkng@irtf.org
References: <p06240825c8c7fd5ca338@[10.20.30.163]>
In-Reply-To: <p06240825c8c7fd5ca338@[10.20.30.163]>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms020805010804000400010006"
X-MailScanner: Found to be clean by mailhub2.dartmouth.edu
X-MailScanner-From: massimiliano.pala@dartmouth.edu
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: Fri, 01 Oct 2010 20:05:06 -0000

Hi Paul, all,

as I wrote in my previous post, the lack of spare time (and funds) prevented me to
start working on the PKI-NG, although I do really think it could potentially impact
(finally) the whole Internet by providing a more usable trust infrastructure deployment
system/support/etc.

I recently (well.. this year!) published the ideas about how to solve some of the
most important issues we face today (let me know if you need a copy):

   http://portal.acm.org/citation.cfm?id=1750389.1750404

[sorry for the self-reference, but I think this could provide the group with
  an initial working item]

The basic idea is to provide the Internet with a support system for:
- PKI deployment
- Interaction between clients and PKIs
- Ease service discovery
- Allow for Trust Anchor simplified management by allowing users to
   trust Federations of CAs instead of having to trust each CA separately

My idea would be to provide two documents. The first describing the overall
infrastructure and the PKS distributed protocol. This is the protocol that
would allow PKI-to-PKI interactions via a distributed P2P overlay network.

By implementing it, PKIs could be enhanced by:
- making it easy for applications to discover and use existing PKI services
- making it easy to add new services or remove existing ones by routing
   messages on the distributed network
- potentially reducing the size of the certificates since not much info is
   needed in the certificate anymore besides the identifier of the issuing CA
- allowing PKI-to-PKI services (e.g., request about the status of key material -
   is this p-key compromised ? To avoid weak or compromised keys to be used
   across different PKIs)

The second describing the client-server protocol for Public Key Operations. Like
the DNS, I envision the presence of local PKS nodes that would act as gatways
for applications for interacting with the PKI network. This protocol could use
HTTP to be compatible with today's clients, or use a more efficient binary one
to boost performances and lower implementation errors/bugs.

What I published is a possible starting point for a discussion on the matter
if people here in the list are interested in providing a PKNG support system that
allows for PK services to be deployed easily and new services/trust models to
be built and deployed on top of it.


Later,
Max


On 09/28/2010 04: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.