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

[Stephen Kent <kent@xxxxxxx>]

Lynn,

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

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.

>This even works in SSL and other types of environments. Consumer's
>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.

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

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>

>as alwas choice is:
>
>1) fully defined, identity certificate

What is this, exactly?

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

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