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

From: [email-masked]
Date: Sat, 17 Jul 1999 13:27:16 -0700

a cert-less approach is relatively trivial to apply across the
corporate electronic environment. register the employees public
key in a RADIUS administrative data-base (i.e. RA by any other
name) and use RADIUS protocol for all corporate authentications
i.e. existing RADIUS based authentication and straight forward
apply RADIUS protocol to future applications.

This even works in SSL and other types of environments. Consumer's
authentication at the server is done with RADIUS account-base.

This doesn't say anything about eliminating web server comfort
certificates ... for setting up SSL sessions ... just addresses issue
of authenticating individuals in environments that are really account-base
operation.

The RADIUS protocol also addresses things like permissions
... again not carrying sensitive individual information in credentials
like certificates ... but going to the account record to obtain the
permissions and operational characteristics.

as alwas choice is:

1) fully defined, identity certificate

2) relying-party-only certificate where the transaction has to
hit the account record.

either all the necessary information is in the certificate or the
certificate contains only enuf information to be able to get
to the account record. if the operation has to hit the accound
record anyway ... then it is trivial to show that the certificate
is redundant and superfulous.

it wasn't intended to be a red herring statement ... it was a
statement that is was one or the other ... either all the necessary
information is in the certificate (in which case the certificate can
represent a privacy and/or security issue) or the information is
in an account record (in which case the certificate is superfulous
and redundant).

this of course, doesn't apply to saying that the merchant comfort
certificates (using for setting up SSL sessions) are unnecessary
... but that almost all cases that the certificates for employees
and individuals ... tend to either 1) divulge privacy/confidential
information or 2) have to hit an account record.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Jul 1999 16:16:02 -0400

Lynn,

>apply RADIUS protocol to future applications.

How exactly does this match with the details of existing, standard
protocols, such as IPsec, SSL, and S/MIME?  I can imagine a scheme by which
this could be made to work, but since these protocols have explicit
provisions for cert (usually X.509 cert) transfer or retrieval., I suspect
that the suggestion you make here is not really compatible with standards
compliant protocols of this sort.  I agree that one might choose to build a
custom application on the basis of cert-less operation.

>authentication at the server is done with RADIUS account-base.

SSL has a specific mechanism for using a client cert for authentication as
part of the SSL handshake.  I don't see how this matches your example,
above.  I think that a browser and server, without modification, will not
be able to take advantage of a client private key based on your description.

>of authenticating individuals in environments that are really account-base

We agree that server certs are not the issue here.  But, the standard way
for a cleint to use a public key for auth is as part of the SSL exchange.
Are you proposing a new, independent user auth operation?  If so, then I
agree one could do that, perhaps with a plug-in, but we already have a
means of using a client cert for authentication in SSL, and we have tens of
millions of browsers that are capable of generating key pairs, requesting
certs, and passing certs to servers in a standard fashion.  So, why change?

<snip>

>1) fully defined, identity certificate

What is this, exactly?

>information or 2) have to hit an account record.

A third choice is to send along an attribute cert (or to embed
authorization data in the public key cert), which is how capability system
is supposed to work (as per the last 25 years of infosec).  This avoids the
need to "hit the account" record, unless access is based on a dynamic
parameter, e.g., for credit card transactions, which is not characteristic
of most intra=net access controls.  In this fashion the organization can
include whetever form of )local) ID it deems appropriate, and the user can
pass in whatever form of authorization credentials are appropriate for the
resource being accessed, avoiding the need for an account record access.
The resource manager does need to check for revocation of the certs in
question, but that may be a cacheable list not requiring the same sort of
off-server access that folks may be envisioning.

Another observation is that the databases for public key management and
authorization management may differ.  If so, a cert-less design might
require two different accesses, one for the public key and one for the
authorization data.  Also, one needs to protect the public key while in
storage and, if the server for the public key is not local to the resource
being access, during  transmission, which is just what a certificate does!
So, cert-less use of public keys does have some possible downsides,
depending on the context.

Steve