Subject: [pkng] Some more wacky ideas...

From: [email-masked]
Date: Thu, 12 Nov 2009 09:43:33 -0000 (GMT)

...none of which are even a bit thought through yet of
course:-)

1) Whatever formats we end up with carrying about keys and
other stuff, I'd like selective field confidentiality to
the max. (Up to and including encrypting the public keys
as well since they expose identity pretty well:-)

2) I want zero-or-more of everything in any structure
(keys, identifiers, locators, blahs...) and to be able
to express relationships between those ("two of these
keys are needed for banking," "any of these keys for
family"...)

3) I'd like to think about the private key holder never
seeing anything like a cert. In many cases, its only
the RP (or a service acting on its behalf ala XKMS/SCVP),
who actually needs whatever structure is involved. That
could push any enrollment burden onto the beneficiary,
which'd be nice. (And in that case, different RPs should
be able to share the burden between them, if the private
key holder is ok with that.)

4) Not all clocks are accurate so I want something that
doesn't need any real time clocks at all, (its ok to use
'em sometimes though).

5) There're probably a bunch of crypto papers about RSA
like keys with more than two factors, split-keys, etc
and they should just work as well as more traditional
keys if they're useful. Not sure how to map that to a
story, but maybe related to different keys having
wildly different crypto APIs associated with them. Maybe
I'll even send you the runtime for that with the key.

6) I want something that works with load-balanced
services - it should be cheap to use whatever we want
to do without having to do it all over again each
time I talk to a different VM or whatever.

7) DTN scenarios, where you can't wait on a round-trip
and sensor-networks where you can't send big packets
should be considered, but are probably corner-cases.
(We might learn from them though.)

8) (Ignoring Paul's instructions:-) I'd like to be able
to hack whatever we do so that the results look like an
X.509 cert so not all PKIX-consuming protocols would have
to know we're messing about under the hood. (Or, put
more soberly, I'd like us to consider migration:-)

9) I'd like some "soft" failure modes, so people (users
or developers) don't have to get stupid PKNG errors to
replace stupid certificate errors. ("Please Mr. RP: If
nothing else works, would you let me do *something*
based on this key?") Put another way: all keys are
valid, some are just better-suited than others for
a particular purpose. (Could revocation even go away?)

10) I want to be able to develop an application so
that when I protect application layer PDUs, then
different receivers get to see different parts, maybe
according to some complex set of rules. (We have a
project on securing electronic health care records
starting in March and this is a requirement for that,
that can probably only be met very clumsily with
current PKI.)

That's enough for now...

S.

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 12 Nov 2009 11:09:50 -0500

Hi all,

just adding to the list of things we could explore... (Paul,
are you keeping track of all the proposals so far ?), I think
we shall look into keeping the PKNG easy - or, at least, relaying
on some concepts that are easy for the users AND for the
developers. Ease-of-Use = less deployment, implementation
and usage errors.

I am saying this because one big problems we have with PKIs
today is the complexity of the protocols on one side and of
crypto libraries on the other. As a result, augmenting apps
with PKI is a painful process. Many developers have no idea
about what they are doing... so... we still rely on passwds
for the majority of our security needs.

Summarizing: we shall keep an eye on usability for users,
developers and pki managers.

I also really like the Stephen's (Farrel) idea of allowing
for a transition to the PKNG when and if needed.. so keep it
at a high-level of abstraction + technical details.

Also, and this is my last point, as we have seen the need for
isolated PKIs to federate (most of the time AFTER they have
been deployed), I would suggest investigating (and I am totally
volunteering for this) mechanisms to integrate existing and
future infrastructures. In more details, I was thinking about
using Peer-2-peer technologies to provide a sort of PKNG
overlay network for secure communication between PK-nodes
(more for CAs nodes rather than End Entities nodes - for
usability and ease-of-deployment considerations).

Cheers,
Max

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 13 Nov 2009 14:41:32 +0900

On 11/13/09 1:09 AM, Massimiliano Pala wrote:

> as we have seen the need for

Forgive me for being an IM guy, but when it comes to personal trust
online, for many people the buddy list is the center of the universe. I
like the idea of person to person trust because it could be represented
or instantiated in the buddy list, and that would feel natural to a lot
of people. The idea of the buddy list could be extended to application
servers, CAs, and other such entities (in fact we have been exploring
that in the Jabber community for incident reporting between servers).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 13 Nov 2009 21:21:02 -0500

Hello Peter,

I understand what you say.. maybe we see things from two very different
point of view. To me, if you trust already your buddy-list is because you
already have some sort of relationship with someone. That is a viable
approach for humans. It has two problems though. First, it does not scale
outside the number of people you interact with, even more when it comes to
extend the trust over the internet.. particularly in this case, I think it
would be better to provide the user with the possibility to extend the
trust from few, well known authorities (we usually do not interact with
that many, directly) in some easy fashion, instead of applying a peer-to-peer
policy. My point being, we need some kind of authority...

Second, when you try to extend the concept to devices (phones, cars, house
appliances, etc..) well.. the buddy list is something we do not really have..
so the user-centric model, like PGP, is would not really work without heavy
user interaction... and not on the Internet, IMHO.

This said, it could be interesting analyzing what can be done when the
two models are combined in a sort of bi-dimensional space...

My sqrt(4) cents...

Cheers,
Max

-- 

Best Regards,

	Massimiliano Pala

---

From: Leif Johansson <[email-masked]>
Date: Sat, 14 Nov 2009 23:03:18 +0100

> Forgive me for being an IM guy, but when it comes to personal trust

Thats ok, somebody has to :-)

> that in the Jabber community for incident reporting between servers).

Incidentally, buddy-lists _is_ the way a lot of SAML identity
federations are build today - using SAML metadata to represent the
list of entities in your ring(s) of trust (entities being services, not
people in this case). The challenge is scaling the buddy-list (or
white-list) to 1000s of entities and beyond. Also the KARP trust model
is exactly a buddy-list too.

Maybe we'll be building something that can both exposed as an online
service - perhaps a mix of CA and OCSP - and something where the
messages of that protocol can be useful outside the context of any
protocol interaction.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Mon, 16 Nov 2009 12:51:49 +0100

> policy. My point being, we need some kind of authority...

I think we need both! Using my inter-networking analogy the BGP peer
sets up peering relationships (== buddies) with those peers it has
traffic with (== require trust for) and then buys transit (== generic
trust) from a small set of transit providers to cover the rest of the
Internet.

	Cheers Leif