Subject: RE: Software for PKI

From: [email-masked]
Date: Thu, 8 Nov 2001 09:37:04 -0700

One of the problems is that there is significant trade-off between identity
schemes and privacy issues. It is possible to authenticate that something
is authorized w/o leaking identity information and therefor improving
privacy.

There has been some talk about EU making electronic financial point-of-sale
transactions as anonymous as cash, aka remove name & other identity
information from debit/credit cards .... both the plastic and the
magstripe. A problem is that the traditional X.509 "identity" certificates
typically represent a horrendous and totally unnecessary leakage of privacy
information.

Some number of EU financial institutions have attempted to address the
horrendous privacy & totally unnecessary identity leakage with X.509
identity by going to relying-party-only certificates .... basically a
certificate signed by the financial institution and essentially containing
only an account number and a public key.

As an aside, for financial transactions ... it is trivially possible to
show that for relying-party-only certificates it is possible to

1) optimize the size of the certificate to zero bytes since the
relying-party that is receiving a transaction with the appended certificate
already has a superset of the information contained in the certificate;
including the public key

2) eliminate the appending of the certificate to the transaction as
superfulous, redundant, and unnecessary since the relying-party already has
the original of the certificate (aka the relying-party manufactored the
original certificate, stored it in the account record, and returned a copy
of the certificate to the client).

Very few electronic transactions are about identity, they are about
authentication and authorization. If a bank gets an ATM transaction from me
.... they don't really care to know who I am ... they want to know if I'm
the authorized party to perform transactions on the specific account.
Throwing in identity into such a scheme just results in all sorts of
privacy exposures and unnecessary identity leakage.

For a guard at a gate to know my name is pretty superfulous .... the guard
just needs to know if I'm authorized to pass the gate. They may check my
face against a badge authorizing me to pass .... not because they want to
know who i am ... they want to know does the authorization badge really
belong to me.

misc. discussions about biometrics and 3-factor authentication:
http://www.garlic.com/~lynn/aadsm2.htm#privacy Identification and Privacy
are not Antinomies
http://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature
initiative stalled
http://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech12 cardtech/securetech & CA
PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re:
KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION
:draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX ....
password/digital signature
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about
Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about
Digital Signatures
http://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose14 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose15 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic
signatures
http://www.garlic.com/~lynn/aadsmore.htm#biosigs2 biometrics and electronic
signatures
http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital
Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
http://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
http://www.garlic.com/~lynn/aepay3.htm#x959risk3 Risk Management in AA /
draft X9.59
http://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY
http://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security
Workshop
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/99.html#157 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#160 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#165 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#166 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#168 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#170 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#189 Internet Credit Card Security
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2000.html#60 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2000f.html#1 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#7 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the
wall?
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001g.html#1 distributed authentication
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
http://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean
Anything?
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security

[email-masked] on 11/8/2001 5:51 am wrote:

I am not sure I agree with the statement that no one really cares about
identity.  How can anyone "know what you are authorized to DO" if you are
not confident that you are who you say you are.  Only after proper identity

has been established can proper permissions be assigned.  PKI is all about
identity management and it may be the most effective method of identity
management on the market today.

these other significant benefits.

PKI and Identity management is a foundation service just like the network
infrastructure and directories.  You build a strong foundation and
construct your application architecture in a manner to leverage the
strength of the foundation.

---

From: Mitchell Arnone <[email-masked]>
Date: Thu, 08 Nov 2001 12:35:17 -0500

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!

The first place PKI must be embraced is corporate (america, europe, asia, 
africa... etc).  Again, I can see the privacy argument but that is not the 
issue or concern I am attempting to address.  I would like to see PKI be 
embraced by every corporation or business in the world but if we wait till 
all the moons are in perfect alignment, it just won't happen.

Those of us on the front line need to get the message out that corporate IT 
can use PKI to solve the more obvious problems now while the rest of us who 
work behind the scenes continue to address issues like privacy, application 
development, standards and etc.  PKI will evolve if we don't kill it first.

Mitch

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 12 Nov 2001 07:20:00 -0500

Lynn:

Good grief.  You are a smart guy.  Do you say these things just to provoke 
reaction?

There is nothing in X.509 or PKIX that warrants such statements.

The whole point of a public key certificate is to bind a public key to an 
identity.  The form of the subject identity can be application 
specific.  For example, to support S/MIME, the certificate binds an 
electronic mail address to the public key.  To support a anonymous payment 
protocol, the certificate would likely bind the public key to an identifier 
of the financial institution and an account number, where only the 
financial institution need know the identity of the account owner.  This is 
clearly the opposite end of the spectrum from QC defined in RFC 3039.

Do not condemn the public key certificate because one application makes use 
of a different form of identity than another application.

Russ