Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))

[Lynn.Wheeler@xxxxxxxxxxxxx]

there would also appear to be a semantic problem here .... public key can be
used in lieu of passwords to authenticate.

digital signatures have a lot of advantages over passwords .... like the method
of authenticating the digital signature (the public key) is not prone to
password compromise (eliminating the problems with having a single password
across multiple organizations and/or having to write down the passwords if
unique passwords are alwas selected).

certficates are one method to authenticate the public key ... but there are also
certificate-less PKIs that use other methods of providing the public key.

the dominate authentication application across the whole internet sphere is
RADIUS (ISPs, corporate networks, intranets, extranets, etc). A simple upgrade
method has been demonstrated for radius that registers the public key in place
of the current business processes that register a password (selectively on an
account by account basis) ... and then digital signature authentication is used
in lieu of password authentication.

One of the simplest issues is that a standard X.509 "identity" can represent
privacy invasion and/or violation of privacy mandates if full name/details are
available ... or if relying-party-only certificate is used .... it it is trivial
to show that if the authenticated transaction has to hit an accound-record (like
logging on to an ISP and the ISP wants to know if your account is still active
... and hasn't been voided because of something like spam'ing) then having the
certificate is superfulous and redundant since the public key can be extracted
from the account. it also eliminates any question of legal issues that having
been shroading certificates in the area of trust-propogation

The interesting thing is that certificate-less PKIs tend to preserve exactly
existing authentication business processes .... while at the same time being
able to utilize off-the-self digital signing protocols/technology (just
forgetting to append the certificate when sending off the transaction, or if you
will, using knowledge-base compression to compress the size of the certificate
to zero bytes).

In that sense, certificate-less PKIs are one of the most aggressive applications
of KISS (elimination of redundant and/or superfulous business processes when
there are perfectly good processes in place today).



.




Stephen Kent <kent@po1.bbn.com> on 07/16/99 12:04:48 AM

To:   Eric_Guerrino@LNOTES5.bankofny.com
cc:   "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject:  Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D
      ACTION :draft-ietf-pkix-scvp- 00.txt))




Eric,

>I couldn't agree with you more. However, regarding acceptance of PKI
>technologies by large organizations, I believe there are many reasons
>organizations are not adopting PKI readily besides ease-of-use issues. Nor
>does it have anything to do with ASN.1 vs XML. This issue can't be resolved
>with technology solutions because their lack of acceptance is not due
>solely to technical problems.
>
>The problems with PKI are numerous, from a corporate perspective, and many
>large organizations have not moved initial PKI efforts beyond the
>pilot/evaluation stage. Problems include outstanding legal liability
>issues, the lack of fraud protection laws, the need to address cessation of
>activites of a CA and/or a registry, the inability to bind a certificate
>distinctly to a user (software certificates identify systems, not users),
>the inability of an issuer to associate a security policy with the
>certificate (issuers need to be able to dictate when to allow caching of
>passwords,as well as things like session timeout and password construction
>rules), undefined procedures and products to support records management and
>archiving, as well as that non-repudiation claims for current PKI products
>may have no legal basis. Then there are all the technical problems.

I agree that these are precieved problems that hinder PKI deployment, but I
also think that many of these are red herrings.  If I use certificates to
authenticate users, in lieu of passwords, why are there any new legal
issues?  Part of the problem is that people have been led to believe that a
PKI must support non-repudiation, which generates a large number of valid,
legal concerns.  However, use of a PKI to support SSL, IPsec, and S/MIME
(at least on an intranet basis) does not raise such issues, yet promises to
improve security and to make life easier for users.

I disagree with your statement that a certificate in software binds a
system, vs. a user.  Yes, smart cards are preferable, but if the choice is
between a password and a certificate (and private key) with software
cryptography, I see no reason not to adopt the latter, and I certainly see
no reason to declare that the latter is not a user (vs. system)
authentication mechanism.  Finally, why do you say that an issuer cann
associate a security policy with a certificate?  We have the syntactic
means to do so as part of the standard.  Do you mean that we don't have
appplications that pay attention to the policy extension?

Steve