Ken Johanson wrote:
> Anne and/or Lynn have recited so many perceived "drawbacks" to x509 in
> general, even in light of their usage in just about every modern
> security / identity communication system of late. But what
> *constructive* suggestions to improve the supposed deficiencies, have
> they offered? What specific technology are they claiming is a
> good/better replacement (some patent-pending technology of theirs
> perhaps?)? And why do they so repeatedly recite "used to be"
> limitations, but not also mention (or show awareness of) the current
> state of the art fully address those?

so there is some complete agreement with the SSL domain name
Certification Authority industry proposal to have domain name owners
register onfile public keys when they register domain names.

rather than just restricting the use of realtime, online, onfile public
key use to just validating digital signatures on communication with the
domain name infrastructure and for ssl domain name digital certificate
applications ... enable access to the online, onfile public keys
available to everyone in the world. Then everybody has online, realtime
access to the real public keys w/o having to resort to redundant,
superfluous, stale, static digital certificates ... and can also
optimize the SSL protocol chatter.
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh

another trivial case is the x9.59 financial standards protocol which was
designed to preserve the integrity of the financial infrastructure
for all retail payments. the paying entity has a pre-existing
relationship with their financial institution. the paying entity's
financial institution keeps some amount of information about their
account holders. one of the pieces of information about their account
holders, is the account holders' public keys. If the paying entity's
financial institution already has the registered public keys for all
their account holders (as well as other registered information), it is
trivial to demonstrate that it is redundant and superfluous to append
stale, static digital certificates to transactions sent to the paying
entity's financial institution for authentication and authorization.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

so the next step is to trivial show that when the relying party has
direct access to the real information .... say in the case where the
authoritative agency for domain name ownership has onfile public keys
for the domain name owner and is willing to provide real time access to
such information, the stale, static digital certificates (representing
that registration and certification) is redundant and superfluous.

Another is any case, where a registration and certification authority is
providing for online real-time business processes in support of digital
signed transactions. If the relying party trusts a certification
authority to issue a stale, static digital certification that can be
used for authentication ... relying parties may find it even more
valuable if the certification authority would provide real-time
authentication and authorized transaction (even taking financial
liability) for digital signed transactions. Since they can be the same
registration and certification authority in both the offline, stale,
static digital certificate scernario (a credential/certificate
representing some real certification business process for purely
authentication) and in the real-time, online support of digitally signed
transactions (which can include authorization and liability in addition
to the sense of any authentication).

It turns out that one of the shortcomings for accepting liability in the
financial transaction case with respect to the offline digital
certificate model ... is the one hundred checks of $100 each (i.e. the
digital certificate can emulate the business check scenario and say the
certificate is not good for any checks over $100) or two hundred checks
of $5000 each. The digital certificate just provides a method for
authenticating ... and potentially could include a maximum per
transaction limit (following the stale, static business check
methodology). However, the infrastructure was still vulnerable to
aggregation attacks ... and the countermeasure was online transactions
that supported not only per transaction rules but could also support
aggregation rules ... something not easily done or controlled with an
offline, stale, static paradigm.

The online, integrated authentication and authorization model could
provide both per transaction business controls as well as aggregated
business controls. Once you have an online, integrated authentication
and authorization paradigm ... it makes the offline, stale, static
processes redundant and superfluous.

Ken Johanson wrote:
> If you can't answer to (but only delete and ignore) the obvious
> questions that were posed to you, then there is no conversation to he had.
>
> And you are *still* referring to what was, instead of now, and
> distorting things merely to support your side (statements like "grossly
> overloaded" and "was redundant and superfluous" (again without an
> example) which are as much balderdash as saying that your drivers
> licensee being overloaded just because it makes you accountable and
> traceable to everyday people you may encounter).
>
> If you don't like it, then don't use certs. For now, they're optional --
> (unlike your drivers license)... even though they are far and away and
> growing as the most used system for secure internet protocols, whether
> issued by the CAs that you despise, or by your own personal CA.

re:
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#34 X.509 and ssh


so the stale, static, offline credential, certificate, license, diploma,
letters of credit, letters of introduction methodology have served a
useful business requirement in the physical world for centuries, namely
providing a mechanism to represent some information to relying parties
who have had no other mechanisms for accessing the actual information.

digital certificates are just electronic analogs of their physical world
counterparts, meeting the same business requirements ... namely
providing a mechanism to represent some information to relying parties
who have had no other mechanisms for accessing the actual information.

so in the mid-90s there were efforts looking at chip-based, digital
certificate-based driver's licenses ... as a higher valued
implementation for better trust and operation.

however, it ran into some of the similar retrenchments that faced x.509
identity certificates ... even the physical drivers license contain
unnecessary privacy information ... like date-of-birth, creating
identity theft vulnerabilities.

the other value proposition justification was that high value business
processes .... like interaction with police officers supposedly could be
better trusted using the higher value and higher integrity chip-based
driver licenses incorporating digital certificate technology.

however, police officers at that time were already in transition to much
higher value online transactions. rather than simply relying on the
information in a driver's license ... the driver's license simply
provided an index into the online repository ... and the police officer
used it to do realtime, online accesses the online respository,
retrieving realtime information for authenticating and other wise
validating the entity they were supposedly dealing with. Any information
(other then simple repository lookup value) in the drivers license,
became redundant and superfluous.

All the higher value driver license related operations, were moving to
online, realtime operation ... leaving any information content
requirements for driver licenses to no-value operations that couldn't
justify an online operation.

If you are faced with a situation where the driver license has very
defined use (say a trivial barcode to index a repository that contains
your complete history and numerous biometric mechanisms for validating
who you area) ... then any additional feature of a drivers license for
use in no-value operations ... needs to be financially justified by the
no-value operations (since they are redundant and superfluous for all
the higher value business processes that can justify doing realtime
online operations).

The online characteristic can also be used to help address some of the
existing identity theft vulnerabilities related to driver's license. For
instance, an individual can authorize ... in a manner similar to how
they might digitally sign an x9.59 transaction
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subtopic...bkey.html#x959

.... a transaction that answers yes/no to whether they are at least 21
years old. the actual birth-date never has to be divulged ... the
certification authority just responds yes/no in a manner similar to how
certification authorities response approved/declined to existing
realtime, online financial transactions.

This is sort of the set "FAST" transaction proposals by FSTC
http://www.fstc.org/

that could even ride the same 8583 rails as existing financial
transactions ... but in a manner similar to answer yes/no to financial
transactions (w/o disclosing things like current account balance or
transaction history) ... could answer yes/no to other kinds of
certifications.

some other past posts mentioning the digital certificate model for
drivers licenses from the mid-90s ... and why it sort of evaporated.
http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
http://www.garlic.com/~lynn/aepay2.htm#position AADS NWI and XML encoded
X9.59 NWI
http://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort
Certificates
http://www.garlic.com/~lynn/aepay6.htm#itheft "Gurard against Identity
Theft" (arrived in the post today)
http://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process,
payment, authentication and identification

http://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate
Revocation Protocol
http://www.garlic.com/~lynn/aadsm7.htm#idcard AGAINST ID CARDS
http://www.garlic.com/~lynn/aadsmail.htm#liability AADS & X9.59
performance and algorithm key sizes
http://www.garlic.com/~lynn/aadsm11.htm#37 ALARMED ... Only Mostly Dead
.... RIP PKI
http://www.garlic.com/~lynn/aadsm11.htm#38 ALARMED ... Only Mostly Dead
.... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#5 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm14.htm#13 A Trial Balloon to Ban Email?
http://www.garlic.com/~lynn/aadsm15.htm#1 invoicing with PKI
http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and
authorization ... addenda
http://www.garlic.com/~lynn/aadsm19.htm#48 Why Blockbuster looks at your ID
http://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet
security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on
high-assurance certificates
http://www.garlic.com/~lynn/2001.html#62 California DMV
http://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001k.html#6 Is VeriSign lying???
http://www.garlic.com/~lynn/2001l.html#29 voice encryption box (STU-III
for the masses)
http://www.garlic.com/~lynn/2001n.html#56 Certificate Authentication
Issues in IE and Verisign
http://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002n.html#40 Help! Good protocol for
national ID card?
http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all
equally secure?
http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs',
how curruptable are they to
http://www.garlic.com/~lynn/2003m.html#21 Drivers License required for
surfing?
http://www.garlic.com/~lynn/2004i.html#4 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005i.html#33 Improving Authentication on
the Internet
http://www.garlic.com/~lynn/2005l.html#32 More Phishing scams, still no
SSL being used
http://www.garlic.com/~lynn/2005t.html#6 phishing web sites using
self-signed certs
http://www.garlic.com/~lynn/2005u.html#37 Mainframe Applications and
Records Keeping?
http://www.garlic.com/~lynn/2006.html#37 The new High Assurance SSL
Certificates

Ken Johanson wrote:
> Let me write you 100 $100 checks... will you cash them all and hands me
> the goods based on my self-generated, unvouched public key? Really?

as stated in other post
http://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh

this was a real business fraud problem ... which businesses responded
with a stale, static credential/certificate (dating some number of
decades) in the form of a check embossed with a stale, static, per
transaction business rule embossed each such credentials (check) with
per transaction limit. some of the digital certificates for financial
purposes even proposed having similar stale, static, per transaction
business rule embosed in the electronic digital certificate (aka not
good for transactions with value greater than xxxx).

the problem that started being addressed sometime in the 80s with
payment cards that were used for realtime, online operation (where the
backend business rules could include a broad range of per transaction
specifications ... but there could also be aggregation business rules
.... that representing real time rules spanning a collection of
transactions) ... was fraud being done by doing using 100 $100 checks or
possibly 200 $5000 checks (whatever the per transaction limit was).

the relying parties liked it much better because not only were they
getting realtime authentication responses back from the authoriative
agency (or certification authorities, if you wish), but they were also
getting back realtime authorization responses (which you couldn't do
using the offline stale, static credential/certificate paradigm)

for the various digital certificate-based financial transaction
proposals ... they went thru all the legacy business rule proposals that
had been used in stale, static credentials/certificates in the past.
however, it was trivial to show that such stale, static legacy
approaches couldn't address the aggregation countermeasures implemented
in online, realtime operations. furthermore, any authoritative agency
supporting such infrastructures could easily have all the information
necessary for both doing realtime authentication and realtime
authorization .... making any stale, static digital certificate
operation redundant and superfluous.

so the stale, static, offline credential, certificate, license,
diploma, letters of credit, letters of introduction methodology have
served a useful business requirement in the physical world for
centuries, namely providing a mechanism to represent some information
to relying parties who have had no other mechanisms for accessing the
actual information.

digital certificates are just electronic analogs of their physical
world counterparts, meeting the same business requirements ... namely
providing a mechanism to represent some information to relying parties
who have had no other mechanisms for accessing the actual information.

for business operations that have moved into an online paradigm with
realtime, online access to all necessary information ... the stale,
static digital certificate methodology represents an archaic, obsolete,
redundant and superfluous paradigm.

ref:
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#32 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#34 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh

so another another scenario comparing online based transaction operation
and offline credential/certificate operation are door badge systems.

the legacy, oldtime door badge systems have been offline. as the higher
value online door badge systems came into being, the offline door badge
systems have moved into the lower cost market niche.

in the 3-factor authentication model
http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* something you know
* something you are

an electronic door badge represents "something you have" authentication.
in the legacy offline door badge system, the badge would present some
unique information that validates a specific badge and differentiates it
from other badges (aka unique "something you have" authentication) and
then some other code that provides the basis for authorization decision
(by a specific door processor). before the introduction of online door
badge systems, the authorization information provided by the badge for
the offline paradigm was becoming more and more complex ... listing
specific classes of doors that were authorized and/or specific doors
that it was authorized. this overloaded the function of the badge with
both "something you have" authentication as well as providing
authorization information for the offline door badge processor.

with the introduction of online door badge, the construct served by the
badge could return to purely a unique "something you have"
authentication. The badge provides unique information to differentiate
itself from other badges; the online system looks up that specific badge
entry and finds the corresponding entity (associated with the badge),
including the entity's permissions and determines whether or not to
authorize the door to open. The online system typically can support a
lot more complex set of realtime permission rules ... compared to
features provided by offline door badge systems ... not only stale,
static per transaction rules, but say a capability to raise an alarm if
the same "something you have" badge is used to enter multiple succesive
times w/o having been used for exits between the entries. This is
comparable to the richer set of features in online payment card
operation ... where set of authorization rules of an online paradigm can
include authorization spanning aggregation of transactions (like has an
aggregate set of transactions exceeded the entity's credit limit) as
opposed to single transaction operation.

now various door badge systems ... whether online or offline have tended
to implement static information to represent a unique physical object
("something you have" authentication). systems relying on static data
representation are a lot more vulnerable to evesdropping and/or skimming
and vulnerable to replay attacks (possibly with counterfeit/cloned badges).

a countermeasure to such skimming/evesdropping (in support of replay
attacks) is a badge with a chip that implements public/private key
technology. the chip has a unique private key which is used to digitally
sign randomly generated data. the relying party then validates the
digital signature (with the corresponding public key) as part of
establishing a unique token in support of a "something you have"
authentication paradigm.

the public/private key door badge, can be implemented in an offline door
badge system, where the door badge is providing both authentication and
authorization information. The chip in the door badge not only returns a
digital signature to the door reader but also a digital certificate. the
digital certificate contains the public key necessary to validate the
digital signature (performing the authentication part of the operation)
and the other information in the digital certificate provides the basis
for the door deciding whether or not to open (authorization). this
technology change is a countermeasure to various kinds of replay attacks
against offline door badge systems.

an online public/private key door badge system implementation doesn't
require a digital certificate since the online entry contains the public
key necessary to validate a digital signature (for a specific badge as
part of establishing a specific unique badge in support of "something
you have" authentication). the online entry also contains the permission
specifications in support of the realtime, online authorization rules.
in the higher value, online door badge system operation, any digital
certificate (providing information for both authentication and
authorization functions) is redundant and superfluous ... since that
information is part of the operation of the online door badge system
The online systems tend more sophisticated authorization rule
implementation, which tend to also be more valuable and more complex
than possible in an offline door badge system using stale, static
authorization rules.

The digital signature paradigm can be viewed as providing dynamic data
authentication countermeasure to skimming/evesdropping (and replay
attacks typically associated with static data authentication
infrastructures). However, the offline paradigm, using a digital
certificate tends to retain stale, static authorization rule
implementation. The transition to online operation can take advantage of
both the dynamic data authentication (provided by the digital signature
paradigm) and also dynamic authorization rules (provided by having
aggregated and realtime information available in the online system).

so the stale, static, offline credential, certificate, license, diploma,
letters of credit, letters of introduction methodology have served a
useful business requirement in the physical world for centuries, namely
providing a mechanism to represent some information to relying parties
who have had no other mechanisms for accessing the actual information.

digital certificates are just electronic analogs of their physical world
counterparts, meeting the same business requirements ... namely
providing a mechanism to represent some information to relying parties
who have had no other mechanisms for accessing the actual information.

a few past postings discussing the offline/online door badge system
comparison:
http://www.garlic.com/~lynn/aadsm16.htm#12 Difference between
TCPA-Hardware and a smart card (was: example: secure computing kernel
needed)
http://www.garlic.com/~lynn/2003b.html#50 Authentication w/o user ids
and passwords
http://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob
Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh

Anne & Lynn Wheeler wrote:
>
>
> so the stale, static, offline credential, certificate, license, diploma,
> letters of credit, letters of introduction methodology have served a

These descriptions certainly implies that x509 certs are "stale, static,
offline credential", again your presentation would lead readers to
believe that (and interpret "stale" as derogatory and diminished value)
this is all the are. In fact, and as you know (but do not present in
balance, on the same sentence, (eg "The static/offline and not live
portion of the certificates"), certs *can* be checked for their validity
during session initiation or periodically, using CRL and OCSP protocols.

This too is a contrast to the (arguable much more stale/static) simple
PKI systems that store trusted keys locally, but have no way to check
some authority to know if those keys were compromised. Again your broke
your own line of argument, where you claim that local "registries" of
trusted key are adequate and state that certificate data (which contains
essential revocation/OCSP URLs) are merely superfluous.

>
> however, it ran into some of the similar retrenchments that faced x.509
> identity certificates ... even the physical drivers license contain
> unnecessary privacy information ... like date-of-birth, creating
> identity theft vulnerabilities.

Is this the only example you can provide, because it's clearly wrong...
Your DOB is *essential* because an entire array of public service
require knowledge/verification of your DOB before you are eligible for
services (over-18 and over-21 activities in the US, and senior citizen
eligibility for services, to name just a few) -- and also because your
DOB helps distinguish one Lynn Wheeler from another.

x509 and personal IDs have not been used because of cost and because of
administrative concerns by govt, and because of portion of the
population believes then should be anonymous and un-trackable of they so
choose.

However this tide is changing - even with proposals to leave those
people in an optional state, other will choose to use digital ID system
because they make *guarantees* against ID theft that paper, passports,
certificates and drivers licenses cannot (including but not limited to
mere photo-copy duplication). Give the choice, I certainly would pick
the digital certificate with 2 factor authentication, compared to
paper/plastic photo ID and payment cards. The paranoid will not, so be
it (they lament having to be registered/traceable with govt but expect
to drive motor vehicles too).

>
> the other value proposition justification was that high value business
> processes .... like interaction with police officers supposedly could be
> better trusted using the higher value and higher integrity chip-based
> driver licenses incorporating digital certificate technology.
>
This is correct.

> however, police officers at that time were already in transition to much
> higher value online transactions. rather than simply relying on the
> information in a driver's license ... the driver's license simply
> provided an index into the online repository ...

You fail to see the point, the non-digital ID can be forged. This is
*diminished* value. I can masquerade as Lynn Wheeler using my fake ID,
and run red lights at your expense. This happens NOW.

and the police officer
> used it to do realtime, online accesses the online respository,
> retrieving realtime information for authenticating and other wise
> validating the entity they were supposedly dealing with. Any information
> (other then simple repository lookup value) in the drivers license,
> became redundant and superfluous.

What you're really trying to propone (apparently) is that and single
user-id (drivers license #) is sufficient, without what you call
superfluous cert data (address, name, etc). Where this breaks down is if
the officer is offline, or the "registry" fails in any way. Central
registries also have complexity and scalability issues, especially when
they must convey all the detail (and not just revocation info) (vs
having all the static details contained inside the cert).

Again, using the trusty x509/SSL example, image if every SSL website
*required* contacting some registry(s) to get details of the company,
instead of conveying the relevant business details during SSL handshake
(eg inside the cert). The system would be both slower and more prone to
failure. And *yet* x509 does allow this to work if the com[pany and
client choose to have stricter requirements -- using meta URLs
referenced in the cert, and CRL/OCSP.

The REAL world example is when you buy something from someone, or when
you crash your car into someone else, and have to exchange
identification data. That person will not necessarily have access to the
registry service. Having all the essential ID data contained *inside*
the cert is purely necessary.

Would you buy something from someone of their ID papers contained *only*
their (supposed) ID #?? You would *not*.

>
> The online characteristic can also be used to help address some of the
> existing identity theft vulnerabilities related to driver's license. For
> instance, an individual can authorize ... in a manner similar to how
> they might digitally sign an x9.59 transaction

The identity theft vulnerabilities of paper and or digital ID system are
merely and artifact of modern day, primitive methods that credit cards
companies use to "authenticate" persons. Specifically, needing your DOB.
These artifacts will disappear with time (as vendors stop using them),
and, they need to access them with will NOT go away (using the very poor
DOB example you provided), because:

a) DOB is simply necessary for modern society
b) they will be registered in a non-permissive system anyway (they
already are)
c) the artifact DOB-type authenticators will stop being used (by law),
and those datums will become innocuous, as they should be. So DOB can be
used to validate your right to enter drink alcohol or gamble, etc, as it
should be and is now.

The permissive model you describe will ONLY be used/useful for things
that *require* permission, like financial transactions. But these datums
(bank account information) do not exist inside of x509 anyway -- only
essential and largely static *identification* data does (and limited at
that, i.e DOB is not required in a most certificates, unless you work
for certain high security agencies).

Put simply your proposing of a registry based system solve-all (where a
user IDs themselves by presenting ID# only) (where signed x509 cert data
is not needed) is flawed and fails by the same tokens you claim the x509
certs fail:

a) redundant over-the-wire transmission of static data when a local copy
can/should exist.
b) required equipment and connectivity to registry (and also *redundant*
registry trust/validation scheme (which x509/SSL already have solved))
c) requires all of the same semantics that x509 already provide for
integrity and authentication.

The permissive model you propose is *only* applicable to *permissive*
data (financial, etc). You're obviously implying that real word ID
information DOB specifically should permissive -- is false, or that
current x509 fields (which current does NOT include DOB) contains what
"should be" private data is false -- if you cause a car accident with
me, then I have complete and irrevocable rights to *positively* ID you
(name, address, DOB together uniquely ID a person in today
permanent-identifier*-less world) so that I can recoup damages (though
some privacy advocates would dispute this "right", they are the exception)

*What you have referred to as a user-id number (which links a person to
the registry) already exists as an RFE, an extended attribute in x509,
where the cert can record and carry your life-long unique identifier.
This too, is nothing less that essential. Again, if *nothing* else
existed in the cert except this permanentID (and all other data
including name had to be sent over the wire), then it *still* needs to
be signed by a trusted party for which I carry a trust store -- so that
I can validate your ID now (before you leave the scene of the wreck),
while I do not have access to the registry, and then get your details
later.

So the x509 and signature system still serves and indisputable purpose,
and clearly having additional fields also in the cert, such as your
*static* name, is fully reasonable (to most people).