Re: X.509 and ssh
- From: Ken Johanson <ken@xxxxxxxx>
- Date: Wed, 12 Apr 2006 09:41:05 -0600
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).
This is correct.
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 ...
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).
- Prev by Date: Re: X.509 and ssh
- Next by Date: ssh.com and pam
- Previous by thread: Re: X.509 and ssh
- Next by thread: Re: X.509 and ssh