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

From: Massimiliano Pala <[email-masked]>
Date: Fri, 01 Oct 2010 15:43:38 -0400

Hello Stephen,

I totally understand your position, and I partially agree. There's a lot
of interest in the keyassure possible WG, but I think the two are actually
complementary.

The possibility of distributing contents via the DNS is orthogonal to the
issues with PKIs: managing the infrastructures, have the interaction between
infrastructures and clients easier, allowing for easy discovery of federated
PKIs and their services, etc.

These are just examples of the issues we face today and there are a lot more
when considering the usage of PKIs in the "Internet of Things".

Bottom Line: the two groups shall have a collaborative approach rather than
a mutually exclusive one :D

Anyhow, I share with you the lack of spare cycles - at least on my side. I
have a lot of good (well, at least I think they are good) ideas to provide
support for Internet PKIs (and Federated identities).

My (good) ideas in my next post.

Later,
Max

On 09/28/2010 05:26 PM, Stephen Farrell wrote:
>
>
> On 28/09/10 21:22, Paul Hoffman wrote:
>> 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.
>
> 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: Massimiliano Pala <[email-masked]>
Date: Fri, 01 Oct 2010 16:07:03 -0400

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.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 01 Oct 2010 16:25:45 -0400

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

i'd be interested in a copy of this paper.

> would allow PKI-to-PKI interactions via a distributed P2P overlay network.

Though we most likely aren't using the protocols you describe (we're not
even relying on X.509), we actually already have something like this up
and running.  The Monkeysphere project (http://web.monkeysphere.info/ --
i'm one of the developers) uses the P2P SKS keyserver network to
distribute OpenPGP certificates, which are in turn used to authenticate
netork peers (primarily HTTPS and SSH at the moment).

We treat any existing X.509 certificates as raw carriers for public key
material, and authenticate the material through the OpenPGP Web of
Trust.  This means using the same PKI (the WoT) for mail, web browsing,
and SSH, which means we have the potential for intuitive UI
consolidation that humans might be able to understand.

It also means that multiple authorities can choose to certify the same
entity, which breaks one of the big stumbling blocks in the way the
X.509 arrangement is currently set up.  (single-certifier certificates
cause CA lock-in for many parties; CA lock-in dramatically increases the
risk of compromise of authenticated networked communications).

I (and the rest of the Monkeysphere team) would welcome any criticisms,
suggestions, or concerns you have about this project.  The system is
already in use, and we hope to see it grow healthily.

Regards,

	--dkg

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 01 Oct 2010 16:30:07 -0400

Dear list...

Since we are discussing the possible activities for the WG...

One small remark (and it could totally lame to remind the list this),
the IPv4 address space assignments are going to run out in less than a year...

My question is: shall we consider the impact of the new address space on
applications and network layer trust ? Is there any special requirement
we shall explicitly consider in the WG work or not ?

Later,
Max

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 01 Oct 2010 16:48:56 -0400

Hi Daniel,

On 10/01/2010 04:25 PM, Daniel Kahn Gillmor wrote:
[..]
> netork peers (primarily HTTPS and SSH at the moment).

It seems to me a good start.. I think we both were going in a very similar
direction although I am more oriented in supporting more classical PKIs
to better address scalability, in my experience PGP tends to work great
in small communities but not so well in large-scale open environments.

My system works best when there's a central body that would provide some
rules (federation) for trusting a set of CAs (eg., Grid Computing). The
user would need to trust the Federation's certificate (and potentially
set a usage context for trusting that particular federation).

> consolidation that humans might be able to understand.

I do really like your approach to support usable UIs - I think that by
fixing the issues at the lower layer (thus simplifying the interaction
with trust infrastructures) we can provide users (and developers) with
easier to understand and clean UIs.

> risk of compromise of authenticated networked communications).

Not sure I understand this comment. I can go and have my keys certified
by different CAs. The different usage and issuer will provide me with
different trust levels depending on the context. I would say that today
it is difficult to express the "context".

> already in use, and we hope to see it grow healthily.

I think it is great that you already deployed such a system. Personally,
if the intent is to provide support for Internet-wide environments, I
would move away from PGP.. although, the support system, could be totally
independent from the format and just act as a discovery system for the
specific technology used. In other words, I think the PKS should provide
support for different PK technologies at the same time - is that possible ?
Well.. that's our work to find out, isn't it ?

-- 

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: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 01 Oct 2010 18:51:35 -0400

> in small communities but not so well in large-scale open environments.

I'm not sure why you say PGP is not as scalable.  Are there specific
protocol concerns you have with it?  or implementation concerns?  other
concerns?

> set a usage context for trusting that particular federation).

Those central bodies are prime targets for potential abuse and failure.
 i'd be happier with no centralized body, and a pool of corroborative
authorities i can select (and discard) depending on whether i view their
interests as aligned with my own (or not) in any given communication
context.

> easier to understand and clean UIs.

yup!  there's a lot of work to be done there, though :/

> it is difficult to express the "context".

You're descirbing a way to get a handful of different certificates from
different CAs.  That's OK for clients, but if you're a server (for TLS
at least) it's not clear which certificate you should display to a new
connection -- how do you know which CAs they'll accept?  Why should they
even have to tell you which CAs they'll accept when you haven't proved
your own identity to them?

instead, as a server administrator, you're currently obliged to either:

 a) limit your audience to a group known to already rely on
certifications from your preferred CA, or

 b) choose one of the "CA Cartel", the group of CAs who are
automatically pre-loaded by most tools (and therefore implicitly
"trusted" by most people).

That will determine which certificate you offer to the client.

Since many public-facing services don't want to limit their audience,
they choose (b), and just pick the cheapest member of the "cartel".

On the other side, the widespread heavy use of the cartel itself means
that end users who decide that the cartel doesn't meet their needs for
authentication have no recourse -- they have many regular connections to
public-facing services (who have all elected to pick from the "cartel").
 So the users can't effectively discard unreliable CAs.

Browser vendors themselves are reluctant to eject members of the
"cartel" from the preloaded lists, because that immediately means cries
of  "$BROWSER broke this popular web site!", and that browser will lose
market share.

Some CAs do actually do good, strong verification in some contexts.  But
those legit CAs who are outside of the "cartel" can't make much headway
(their services are not sought after because of the above).  And Legit
CAs inside the "cartel" are regularly undercut by the less-reputable
members of the group, with no real hope of getting them ejected.

So as best i can tell, browser (and other software) vendors, users, and
legitimate CAs are all stuck in this nasty little logjam.  The only
beneficiaries of it are the least-scrupulous CAs already present in the
cartel.  Not a good outlook for secured communications on the broader
'net.

As best i can tell, a multi-certifier certificate could break the
situation open a bit.

The other problem i see with the centralized (meta-CA) approach you've
described is that trustworthy authentication is not really a
one-size-fits-all model.  I might be fine relying on certifications from
the French government, and you might not.  Even more nuanced, i might be
fine relying on the Turkish government to operate a CA that certifies
.tr domain names, but if the thing they're certifying is within .gr, i
might want to double-check that against some other authority.

i don't know that these decisions can be correctly made at a centralized
place, simply because the central authority doesn't know which of the
entities it is identifying has a potentially adversarial relationship
with which other entities.

> would move away from PGP.

I assume "move away from PGP" means "move to X.509-based certificates".
 Why?

OpenPGP seems to me to already meet our needs for internet-wide
deployment.  What would we gain from dropping it?

I'm interested in concrete reasons for this suggestion.  I realize this
might be heresy on a WG focused mostly on X.509-based approaches, but
i'm actually not trolling or wanting to start a religious battle. :)

If there's something i'm missing or have misunderstood, i would very
much like to hear about it.

> although, the support system, could be totally

i do think that's possible.  our eventual goal is to treat the X.509
certifications themselves as additional corroborative evidence to the
WoT that the user can accept or discard at will.  But i think the
OpenPGP certificate architecture already offers pretty much exactly what
we want: a reasonably well understood, widely-tested multi-certifier
architecture for a distributed PKI.

You can create a fully-centralized scheme using only OpenPGP
certificates, but you aren't forced to do so.  With that architecture,
those of us who don't want centralized schemes don't have to use them,
and those who do can build them too.

Regards,

	--dkg