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

[BalluffiF@xxxxxxxxxx]

Lynn Wheeler is correct. In a closed system (e.g., a home banking system),
it is possible to compress all certificates to zero bytes (i.e., just use
public keys).

Certificates can be used to construct trust hierarchies. Public keys can
not.

The reason SSL is primarily used for comfort is not because there is
something wrong with certificates, it is because the necessary certificate
management infrastructure does not exist. Imagine today's use of SSL without
certificates -- system administrators would be installing large numbers of
raw public keys into browsers, not a few CA certificates.

Frank Balluffi
CertCo

-----Original Message-----
From: Lynn.Wheeler@firstdata.com [mailto:Lynn.Wheeler@firstdata.com]
Sent: Saturday, July 17, 1999 4:27 PM
To: Stephen Kent
Cc: '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))


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.