RE: Software for PKI

[lynn.wheeler@xxxxxxxxxxxxx]

let say it is a bank with bank employees. The bank may be required to run a
FBI check on all employees associated with various kinds of financial
responsibility. That is obviously a identification issue.

however,. for all the authentication and authorization operations that
occur in a banks internal operation .... it is of absolutely no use to know
a person's name for authentication and authorization.

in the point-of-sale & e-commerce scenerio it serves little purpose that a
people's name & address have to be kept in some 20 million merchant web
servers around the world.  All that is necessary is for the merchant to
know that a correct transaction occurs and the merchant gets their money.

In effect, authentication and authorization w/o identification is
sufficient for correct operation. The problem that does crop up is large
amounts of incorrect operation (i.e. insdier fraud is documented as being
the largest type of fraud). For in-correct operation it is useful to have
an audit trail so that it is possible to track back from an authentication
& authorization event as part of financial forensics so that recovery and
remediation processes can be put into effect. However, it is not necessary
to have identity directly invovlved in the direct authentication &
authorization process as part of correct operation.
Part of it, isn't that the corporation might not have to determine at some
point exactly who you are .... but that it is unnecessary to repeatedly
propogate large amounts of identity on every transaction (for fraud, it is
just sufficient that there is some way of tracking a frauduent activity
back to an individual).

The unnecessary propogation of identity related information on transactions
which only require authentication and authorization.

Basically I need to proove that some authentication & authorization belong
to me ... I don't need to proove who i am (although there may be a way of
correlating things that belong to me with who i am).

Following is discussion of picture card ... not for identification purposes
... but for authorization purposes. The ID didn't need name or anything
else. The purpose of the picture was that somebody could check that the
card being used actually belonged to the person using it.
http://www.garlic.com/~lynn/aadsm7.htm

and how authentication and authorization deals with correct operation and
typically identification deals with recovery, remediation, and possibly
deterance.

Now, some number of corporations (besides EU banks for customers) have gone
to relying-party-only certificates .... basically no identification ... but
only an account number .... let's say an employee number. The employee
number has associated with it various authentication properties as well as
authorization properties. Digital signature operations are one form of
authentication in a relying-party type of environment. At the simplest
having a "credential" from a specific employer and being able to
demonstrate that it is your credential is sufficient for certain minimum
authorizations/previleges. However, in the previous posting regarding EU
banks it is possible to trivially show that it is unnecessary, redundant
and superfulous  to append a certificate to a digitally signed message that
is going to the relying party (either by the zero byte compression rule or
the relying party already has the original rule).

So as in the DNS case registering public keys provides an avenue for
totally obsoleting the necessity for SSL domain name certificates .... what
about employee/customer certificates. My previous claim that possibly
99.9999 percent of the exiting certificate related authentication events
are SSL domain name certificates ... and it is fairly straight-forward to
totally obsolete the necessity for such certificates. Also it is possible
to show that is straight-forward to totally obsolete the relying-party-only
certificates in the financial customer transaction case.

What about the employee/client/corporate case? I would also claim that
99.999 percent of the client-related authentication events that happen in
the world today involve RADIUS. RADIUS currently involves shared-secret
and/or challenge/response ... frequently observed when customers contact
their ISP or employees dial into corporate networks. So, it is relatively
straight-forward if a corporation was to register public keys in a database
(i.e. the RA, registration authority, part of a certification authority,
and also store the original of a manufactored certificate there), then the
simplest deployment is to hook up a real-time, online RADIUS infrastructure
to that database and also enable RADIUS for digital signature
authentication.  The message is signed, the message and digital signature
are transmitted and RADIUS authenticates the digital signature with the
real-time, online access to the RA-registered public key. It has the
advantage of being currently deployed infrastructure for 99.999 percent of
the internet, and is an online real-time design point. It doesn't have the
short-comings of a PKI infrastructure designed for the offline, stale,
out-of-date operation with manufactored certificates. Furthermore, any
invention for adding online, real-time to a PKI ... can be done better by
eliminating the certificate all together and directly using the real-time
information.

misc. threads regarding use of public keys in existing RADIUS
authentication and authorization infrastructures;
http://www.garlic.com/~lynn/subtopic.html#radius

For a list of RADIUS RFCs: goto
http://www.garlic.com/~lynn/rfcietff.htm

and click on "Term (term->RFC#)" and then scroll down in the abbreviations
to "RADIUS" and click on "RADIUS".

For a list of authentication related RFCs goto
http://www.garlic.com/~lynn/rfcietff.htm

and click on "TERM (term->RFC#)" and then scroll the frame down to the term
"authentication". Also listed are RFCs from the "Authentication,
Authorization and Accounting" work group, as well as terms related
specifically to authorization. The authentication term also points "UP" to
RFCs that are related to security in general.

You may also find of some interest the security taxonomy & glossary at:
http://www.garlic.com/~lynn/index.html#glossary

there is both the Security specific taxonomy/glossary as well as a X9F
standards taxonomy/glossary
Security
     Terms merged from: AFSEC, AJP, CC1, CC2, FCv1, FIPS140, IATF IEEE610,
ITSEC,
     Intel, JTC1/SC27/N734, KeyAll, MSC, NCSC/TG004, NIAP, RFC1983,
RFC2504,
     RFC2828, TCSEC, TDI, TNI, and misc. Updated 20010729 with glossary
from IATF V3.
X9F
     Terms merged from X9F document glossaries: WD15782, X509, X9.8, X9.24,
X9.31,
     X9.42, X9.45, X9.49, X9.52, X9.62, X9.65, X9.69.
     Terms from ABA/ASC X9 TR1-1999 replace terms from X9F TG-16 glossary
(identified
     by lower case x9 instead of upper-case X9). Original source documents
include: X3.92,
     X3.106, x9.1, x9.5, x9.6, x9.8, x9.9, x9.17, x9.19, x9.23, x9.24,
x9.26, x9.28, x9.30,
     x9.31, x9.41, x9.42, x9.44, x9.45, x9.49, x9.52, x9.55, x9.57, x9.62,
x9.69 x9.74, x9.76,
     x9.78, x9.80, x9.82, and TG-17. (990710)












marnone@xxxxxxxxxxxxxxxxxxxxxx at 11/08/2001 10:35 AM wrote


If I understand your point correctly, you are making reference to the usage

of real human names in certificates.  There is the question of where does
privacy begin and where does it end.  In a corporate office, do you have a
right to keep your name private?  Sure you can be as private as you want at

home and in your personal transactions but I can't imagine a valid argument

for the same level of paranoia in the work place.  Privacy is a very
important concern but even if you use some other form of unique
identification that can not be correlated with obvious private human
information, you are still dealing with identity management.  Your name may

not be included in that certificate but somehow and somewhere there must be

some sort of non-reputable association between that certificate and a
specific human.  This is identity management!