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

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Sep 2010 13:22:17 -0700

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Sep 2010 22:26:52 +0100

> 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…

I believe there could be, but that some of the oxygen has been
sucked out of the room (to keyassure) so I'm no longer sure if
there's a realistic target for pkng, nor whether there're
sufficient cycles for doing work. (I'd be happy if my concerns
are unfounded.)

Assuming keyassure turns into an IETF WG developing some kind
of way to manage public keys in the DNS, (and offers a reasonable
potential successor/addition to X.509), I think this group could
maybe try look beyond that towards pk systems that might start
to be deployed in 5+ years after both X.509 and keyassure are
already out there. But I think we'd have to know where keyassure
is going before re-scoping the work here.

If keyassure founders, then there's a role for this group
in understanding why and maybe working towards fixing whatever
caused the failure. (Assuming the failure is technology
and not personnel;-)

Bottom line for me for now: let's see what happens with
keyassure first before we kill or pump up this group. My
guess is that we won't know until the new year.

S.

PS: I still have that list of things I'd like that I sent to
this list a long while ago.

---

From: Rene Struik <[email-masked]>
Date: Thu, 30 Sep 2010 10:47:50 -0400

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:
> This RG has a charter that was well-discussed; it is at<http://irtf.org/charter?gtype=rg&group=pkng>. In particular:
>
> _______________________________________________
> pkng mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/pkng

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363