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

[Daniel Kahn Gillmor <[e-mail]>]

On 10/01/2010 04:48 PM, Massimiliano Pala wrote:
> 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.

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?

> 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).

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.

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

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

>> 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).
> 
> 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".

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.

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

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

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