Re: X509 digital certificate for offline solution

From: Valery Pryamikov (valery_at_harper.no)
Date: 08/13/05 

Date: Sat, 13 Aug 2005 16:42:16 +0200

<lynn@garlic.com> wrote:
>
> there are lots of scenarios where it is possible to have institional
> management of public keys for authentication purposes ... especially as
> part of overall online operational infrastructure.
>
> PKI, certification authorities, and digital certificates ... were
> specifically designed to address the offline, disconnected, first-time
> communication between strangers where the recipient (relying-party) had
> no other recourse about information.
>
> The original pk-init draft for kerberos just had public keys registered
> in lieu of passwords ... and performing digital signature verification
> (in lieu of password comparison). It wasn't until later that they also
> allowed for entity totally unknown to kerberos to be able to present a
> digital certificate as part of authenticated to kerberos.
> http://www.garlic.com/~lynn/subpubkey.html#kerberos
>
> Possibly one of the most prevalent internet oriented authentication
> function is radius (i.e. in use by the majority of ISPs for
> authenticating their clients when they connect). This has been
> primarily a password based infrastructure ... however there have been
> radius enhancements where public keys are registered in lieu of
> passwords and digital signature verficiation is done in lieu of
> password checking
> http://www.garlic.com/~lynn/subpubkey.html#radius
>
> in both cases it is possible to integrate public key authentication
> into the permission and overall relationship management infrastructure
> w/o having to resort to a redundant and superfluous, duplicate
> relationship management infrastructure represented by PKI,
> certification authorities, and digital certificates.
>
> The basic issue issue for public key and digital signatures is
> straight-forward authentication ... integrated into overall existing
> business practices that manage the entity, their access, their
> permissions, etc.
>
> Typically, PKIs have represented independent infrastructures,
> independent of overall system operation. However, it is possible to do
> straight-forward public key and digital signature authentication
> integration into existing infrastructures w/o having to resort to
> redundant and superfluous PKIs, certification authorities, and digital
> certificates.
>
> A simple sanity check:
>
> if the system infrastructure has some table of entities along with
> related authorizations and permissions ... that is critical to the
> operation of the system ... then it is possible to add public key and
> digital signature verification to that infrastructure w/o having to
> resort to an independent PKI, certification authority, and digital
> certificates.
>
> the PKI, certification authority, and digital certificates were
> targeted at infrastructures that didn't have existing relationship
> management infrastructures. a sanity test of whether or not a PKI is
> redundant and superfluous ... is if the digital certificate provides
> all the necessary information to the operating infrastructure (all
> entity information, all permissions, all access control, all
> authorization) w/o the operating infrastructure needing to reference
> any other information ... then the digital certificate, certification
> authority, and PKI isn't redundant and superfluous.
>
> If the operating infrastructure simply uses information in a digital
> certificate to reference (the "real") repository of entity,
> permissions, authorizations, and/or access control ... then it is
> usually trivial to demonstrate that the digital certificate is
> redundant and superfluous (usually by showing that the public key can
> also be registered in such a respository). Showing that the digital
> certificate is redundant and superfluous ... then it will follow that
> the certification authority is redundant and superfluous and also PKI
> is redundant and superfluous.
>

I always enjoy reading your posts in sci.crypt and cryptography mailing
list! I know your position regarding PKI and I know that you are really good
argumenting your points. There is no doubt that PKI dream as such has failed
to fulfill its purposes. That if you look at each concrete function
supported by PKI - it is always possible to find some better solution...
However, one thing that is very important with PKI is its "standard" part.
It's just as with any other standards. like take for example XML. Is XML the
best possible way of solving problems of semi-structured data on the web?
Absolutely not! It has lots of drawbacks, starting with inability to simply
combine multiple documents into one single document by concatenating them
together... It's easy to argue that XML is over-engineered and too damn
complex (just as it is with PKI). However, whenever we talk about whether or
not we should use XML in real-life applications - the answer is definite
Yes! . Because being a standard gives a lot of ready to use tool, solutions
and practices for solving problems much easier, faster and reliable than it
would be with any home-made replacement of XML regardless of how good this
home-made solution would be at solving some of the drawbacks of XML...

The same thing concerns PKI. It's not perfect; it failed to fulfill PKI
dreams started by Kohnfelder's thesis. One of the biggest problems is that
there is no such thing as universal trust and PKI simply failed to be
adjustable to wide and complex model of trusted/semi-trusted relations of
reality. However it is good in close environment involving several trusted
parties and/or as enterprise-wide Keys Infrastructure solution. And being a
standard is actually a very positive part! If I would have to choose between
two solutions, where the first relies on PKI and other relies on home-made
protocol, I would without a doubt choose former as long as later doesn't
rely on some proven standard (or backed by a well earned reputation). Big
problem with insecurities of nowadays software solution is that it is too
common for most of developers to downplay complexities of designing secure
protocols/security solutions. When I see home-made solution with proprietary
secure protocol, that just gives me shivers and I always advise to stay as
far away from them as possible. However, when developer is given standard -
they will try to rigorously follow it (esp. when they are not very
proficient with underlying mechanisms <grin>).

So, my point is that it is very good to argue against standards (and PKI
particularly) in academic groups - that will ensure that newer and better
standards will be developed later-on. But it is different thing to advice
against using standards in programmers groups without providing proven and
feasible alternatives, because that could negatively affect security of
future software systems.

-Valery.

http://www.harper.no/valery

Relevant Pages

  • Re: X509 digital certificate for offline solution
    ... > doesn't diminish fact that PKI has certain quite tangible value for certain ... part of overall online operational infrastructure. ... PKI, certification authorities, and digital certificates ... ...
    (microsoft.public.dotnet.security)
  • Public Key Infrastructure
    ... Can someone please tell me with regards to PKI (Public Key Infrastructure), ... what exactly do you need, besides the root certficate, in order to establish ...
    (sci.crypt)
  • RE: [fw-wiz] PKI is the pits?
    ... PKI is a disaster because of a combination of technical people ... what we see is that public key crypto ... existed in a vacuum - lacking a survivable business use case ... >deleting the cert. ...
    (Firewall-Wizards)
  • Re: General PKI Question
    ... "If you're encrypting a message your software obtains it from a PKI." ... > encrypt the message with the intended recipient's public key. ... >> message using their private key and the recipients public key, ...
    (microsoft.public.security)
  • RE: [fw-wiz] PKI is the pits?
    ... public key cryptography is far more prevalent that full ... the definition of PKI seem to vary in the eye of the beholder ... authorized certs from gateways or servers ...
    (Firewall-Wizards)