Misc AADS & X9.59 Discussions

AADS Postings and Posting Index, next, previous - home



Huge CRLs
Huge CRLs (part 2)
Huge CRLs (part3)
Why smartcards? (was IP: Smart Cards with Chips encouraged)
valid PKIs
NACHA digital signature pilot
proposed key usage text
Certifiedtime.com
AADS & X9.59 demos at BAI (annual world-wide retail banking) show in miami next week
QC Bio-info leak?
QC Bio-info leak?
QC Bio-info leak?
Debit card fraud in Canada
RFC 2527 Physical Security Controls Question
RFC 2527 Physical Security Controls Question
Digital Commerce Trivia Questions
Killer PKI Applications
Killer PKI Applications
Killer PKI Applications
Killer PKI Applications
Killer PKI Applications
javasoft SET - NO!
The Law of Digital Cash
Smartcard anonymity patents
biometrics and electronic signatures
biometrics and electronic signatures
A proposal for secure videoconferencing and video messaging over the Internet
Client-side revocation checking capability
Client-side revocation checking capability
President Clinton digital signing
"request certificate"
Client-side revocation checking capability
Client-side revocation checking capability
Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
Public Key Infrastructure: An Artifact...
Public Key Infrastructure: An Artifact...

Huge CRLs

From: Lynn Wheeler
To: "Phillip M Hallam-Baker" <pbaker@xxxxxxxx>
cc: "Robert Moskowitz" <rgm-sec@xxxxxxxx>, TeamDaguio@xxxxxxxx, martin@xxxxxxxx, ietf-pkix@xxxxxxxx, cert-talk@xxxxxxxx, alex@xxxxxxxx, tca@xxxxxxxx, thomas_caldenius@xxxxxxxx, nada@xxxxxxxx
Subject: RE: Huge CRLs
note also that for the router/vpn/ipsec scenerio ... that direct analogy for badged entry systems exists which come in both offline (aka certificate) on online (possibly OCSP but also AADS ... i.e. certificate-less) deployments.

Both offline and online versions of badged entry systems currently exist meeting different security and price objectives.

Also, CRL operation tends to be a scaleup issue proportional to the size of the population ... and somewhat independent to the number of transactions &/or connections. Online scaleup (at least for the router) tends to be much more insensitive to the size of the population ... but more proportional to the number of transactions.

However, the online flavor, is in fact, the scenerio used by 99% of the internet routers today for authenticating connections ... i.e. RADIUS and like ilk use online protocol for determining authentication ... and so an online protocol would not be an enormous business process leap to the existing deployed infrastructure (whether it was certificate or certificate-less based online digital signature).

Huge CRLs

From: Lynn Wheeler
To: "Bob Jueneman" <BJUENEMAN@xxxxxxxx>
cc: TeamDaguio@xxxxxxxx, martin@xxxxxxxx, rgm-sec@xxxxxxxx, ietf-pkix@xxxxxxxx, cert-talk@xxxxxxxx, nada@xxxxxxxx, tca@xxxxxxxx, thomas_caldenius@xxxxxxxx, alex@xxxxxxxx
Subject: Re: Huge CRLs
i believe, the claim is, that is exactly the original design point for certificates ... back when it was assumed that was the only operational method of networks, i.e. offline, disconnected, email processing i.e. the "phonenet" method mentioned at

http://www.garlic.com/~lynn/internet.htm

in the internet history thread.

to some extent, the problems are occuring trying to extend something originated for offline, disconnected email authentication into online business processes.

From: "Bob Jueneman" on 09/14/99 08:28:37 AM
On the other end of the time spectrum, try using OCSP, or any other protocol other than CRLs, in disconnected mode while you are on an airplane reading your signed e-mail.

Bob

Huge CRLs

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
To: "Robert Moskowitz" <rgm-sec@xxxxxxxx>
cc: TeamDaguio@xxxxxxxx, martin@xxxxxxxx, ietf-pkix@xxxxxxxx, cert-talk@xxxxxxxx, alex@xxxxxxxx, tca@xxxxxxxx, thomas_caldenius@xxxxxxxx, nada@xxxxxxxx
Subject: Re: Huge CRLs
some of the issues in financial infrastructure

certificate binds some set of information which tends to relatively stable state, certificates don't handle time series aggregation and/or realtime ... the certificate bound information tends to be a subset of the information found in accounts records ... which are the mainstay of current financial infrastructures. the purpose of these certificates is to allow a move away from centralized, account-record processing to independent, distributed processing. emerging issue in the consumer world (including consumer financial world) is the concern about abstracting privacy information for widely distributed processing (i.e. the inclusion of any information in a certificate that might possibly identify the consumer).

CRLs is an attempt to address some subset of the problem represented by certificate information staleness. From a scaling standpoint, CRLs have shortcoming that they tend to be proportional to the population size ... not proportional to the work/transactions performed.

From a financial infrastructure standpoint ... it might be possible to veiw certificates as a means of distributing relatively stable information from account records into offline environments ... possibly involving the ability to perform low-value operations not requiring the timeliness and/or aggregation information dependent on account record implemenations (especially if no identity information and/or anything related to a consumer is involved in the certificate).

However, for financial operations that do have to touch account records (because of possibly something like transaction aggregation, i.e. the current account balance or privacy issues) ... then it follows that not only aren't CRLs appropriate but the certificates themselves are redundant and superfluous (i.e. we can alwas show that for any combination of information that can be bound in certificate ...a superset of that can be "bound" in an account record).

This sort of abstraction then can be used to characterize evern Certification Authority implemenation ... as the Certificate Authority contains "master" account record copies of the information bound into certificates. Certificates can propagate this information into a distributed environment involving an arbritrary large (and possibly unknown) number of locations. CRLs is then an attempt to contact all of this arbritary large number of locations regarding the validity &/or staleness of certificate based information. Therefor, CRL implemenation scaling can be an issue of both proportional to the population size and also proportional to the possible number of locations (i.e. not actual number of relying party locations where actually certificate exists but all possible relying party locations where it might exist).

For arbritrary large certificate population (N) with arbritrary large number of possible relying parties (M) than CRL processing becomes proporational the NxMxI product (certificate population size times relying population size times propability of information becoming stale/invalid).

By comparison a RADIUS and/or centrlized authentication mechanism has processing overhead proportional to the number of transactions. So for an online environment, the efficiency issues becomes whether the
P(NxMxI) > P(trans)

i.e. is the CRL overhead (proportional to size of certificate population times size of relying party population times probability information changes) greater than contacting an authentication server on every transaction.

So at one extreme is online requiring timely, aggregated and/or privacy information access to the account record ... making use of a certificate (with replicated, stale, subset information) superfluous (as well as unnecessary expense and infrastructure especially when information binding & authentication infrastructure already exists).

At the other exterme is offline infrastructure with no existing information binding & authentication infrastructure (aka 1980s offline email) where even replicated, stale, information (bound in a certificate) may better than no information.

In between are online environments needing authentication infrastructure with distributed operation (with possibility of distributed information bound into certificates) vis-a-vis online direct access with higher degrees of information timelyness. The trade-offs come down on the side of certificates with low propability of information staleness, small certificate populations, small number of relying parties, no privacy issues and very large number of transactions. The trade-offs would be away from certificates as the probability of information staleness increases, there are privacy issues, the size of the certificate population increases, the number of relying parties increases and/or the number of transactions decrease.

Systems that have overheads/processing proportional to size of population & not amount of work performed (or number of transactions) tend to run into scaling problems ... if nothing else funding & processing capability tends to be size based on amount of work being done ... as opposed to size of pupulation.

As an aside, one characteristic contrasting the certificate-based processing as fully distributed (potentially even down to both physical and logical point-of-sale) and account-based "centralized" processing ... the current account-based consumer electronic financial processing is hardly centralized. All transactions against a specific account are routed to the processing unit responsible for that account ... but there is a large (somewhat mesh) network interconnecting millions of point-of-sale with possibly tens of thousands of account-record processing locations.

Why smartcards? (was IP: Smart Cards with Chips encouraged)

From: Lynn Wheeler
To: cryptography@xxxxxxxx
Subject: Re: Why smartcards? (was IP: Smart Cards with Chips encouraged)
significant amount of the credit card infrastructure costs is to cover advancing the money for payment and various kinds of unauthorized use of cards ... including by merchants (one of the reasons why it may be difficult to get merchants authorized)

SSL doesn't take into account any of those issues.

X9.59 (draft financial industry standard for all account based payments) can eliminate most forms of unauthorized use ... reducing infrastructure costs ... along with the possibility that it can somewhat reduce the difficulty of merchant be authorized for taking transactions since it eliminates some part of risk associated with authorizing merchants. however risk of merchant not fullfilling delivery service/product still remains ... but that is true for all forms of payment, the question for the consumer vis-a-vis credit-card mode is the advantage they gain from having their bank help in delivery-versus-payment conflicts (DVP has been issue in commerce for a long time and exaserbated in distance & non-face-to-face transactions).

however, X9.59 is agnostic with respect for use as credit or debit payments (both types flow over ISO8583/ISO8583-like networks).

valid PKIs

From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: valid PKIs
recently there were assertions about valid PKIs involving:
    only ASN.1 encoded messages & protocols are valid for carrying information that has been digital signed ... i.e. it is not possible to encapsulate &/or change information representation ... invalid scenerios would be: a) legacy networks & protocols, b) hardware compression, c) packaging ASN.1 encoded messages in ATM cells
    the only valid digital signature transmission is one that alwas has the corresponding public key certificate attached ... an invalid scererio is any certificate that isn't a self-signed certificate and doesn't include in the transmission the corresponding key-signing certificate (in a trust hierarchy all the associated certificates must be appended on every signed transmission).
    all valid PKI operations in all contexts requires that they all be ASN.1 encoded certificate operations ... an invalid scenerio is internal Certification Authority business operations that stores certificate related information in RDBMS directly as data fields and directly performs internal business operations using standard SQL statements ... example includes OCSP implementation using a certificate ID and a certificate status field implemented directly in a RDBMS (OCSP is an invalid operation if it directly looks up a certificate identifier in a database and extracts a related status field ... reasons for being invalid includes the data stored in the database is not in ASN.1 encoded.


In particular, the assertion was with respect to relying party Certification Authorities which avoided having to have the certificate transmitted back to them (in part, for privacy reasons) since the relying party certification authority already holds the original of the certificate.

ref:

http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2

NACHA digital signature pilot

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: NACHA digital signature pilot
The NACHA pilot was described at FSTC this summer as being AADS-like ... there has been some offline discussions about possibility of coverging formats to X9.59 specification (although possibly using X9.59 fields but with SDML encoding). See


http://www.nacha.org/whats-hot/press/1999/ATMPilot.htm

and for x9.59/aads see http://www.garlic.com/~lynn/

and example of the mapping to 8583 see

http://www.garlic.com/~lynn/8583flow.htm

the bottom of this web page has a sample the signed x9.59 fields in tagged format encoding (as opposed to ASN.1 encoding).

Also, as interesting exercise, the mapping of AADS business practices into CADS Policies and Practices statements

http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2

proposed key usage text

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: proposed key usage text
we are doing something like that for AADS radius (i.e. being able to upgrade something like 99% of the current internet ISP authentication infrastructure to digital signature authentication). The strategy is that the ISP sends a challenge string ... basically somehting like "please authenticate 'userid'" with a time-stamp/nonce (in lieu of the "please enter password" message), the user then adds their own nonce, signs it and returns it. Having webserver products at the large web farms also support radius ... then allows a single authentication administrative infrastructure for the majority of existing internet operations.

Aram Perez wrote:
But how do you distinguish between what use was intended? If someone captures a message that I signed for "authentication and integrity" and another message that I signed for non-repudiation, how does a third party distinguish which use was intended?

I have seen many authentication protocols that require the party being authenticated to sign a challenge (that is supposed to be a random number or a nonce). Now suppose that I'm trying to get access to a system that instead of sending me a random challenge, sends me the following message: "I agree to sell 1000 shares of Apple at $10.00 per share." My software will blindly sign the message and send my certificate which has the DS and NR bits set. Am I now obligated to sell 1000 shares of Apple at $10.00? Can I prove to a third party that I was only trying to do authentication and not non-repudiation?

Regards,
Aram Perez

Certifiedtime.com

Refed: **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: Certifiedtime.com
note that the AADSS radius case with time-stamp/nonce is a replay-attack scenario and so it doesn't really require real-time.

this particular is more akin to virtual time work on log merge. when i was doing cluster distributed lock manager work ... misc. ref:
http://www.garlic.com/~lynn/96.html#15
http://www.garlic.com/~lynn/95.html#13

i had also worked out the process for doing cache-to-cache buffer copies w/o having to do the disk write first. this made several of the database people uneasy since various failure mode recovery scenarios required doing log merging between the different nodes. in part because it was a closed system, "virtual" time providing relative ordering of the entries for the same record in different logs was sufficient (the distributed database & filesystems guys have recently picked up renewed interest in this area).

reliable "real" time becomes an issue when trying to prove relative ordering in an open infrastructure (possibly even involving real world, non-computerized events) as opposed to "virtual" time which can be used in closed systems (like large distributed cluster databases & filesystems ... something even as simple as a version #).

There are numerous financial and contractual events that would benefit from being able to show real-world ordering.

AADS & X9.59 demos at BAI (annual world-wide retail banking) show in miami next week

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: AADS & X9.59 demos at BAI (annual world-wide retail banking) show in miami next week
AADS X9.59 (reference implementation) integrated with one of the major web merchant systems looks like it will be demo'ing in several booths at next week's BAI show in miami. It will use aads digital signature chipcard for signing the x9.59 transaction.

In addition, the AADS FSTC/FAST-like demos are also working, i.e. age, location, etc. and will be at the show (for instance allowing verification of non-minor status before allowing to proceed at a website). This will be able to use the same aads digital signature chipcard.

The only demo that might not make to the show is the AADS RADIUS demo (i.e. RADIUS is utilized by the majority of internet service providers around the world to authenticate connections by their customers ... as well as the major method for dial-in authentication to corporate intranets). This will also will work with the same AADS digital signature chipcard.

The AADS operations can be done securely w/o divulging privacy information. X9.59 financial transactions can be w/o requiring name & address. Signed AADS shipping transactions can be done allowing web sites to ship hard goods w/o requiring name&address. Minor/non-minor status can be affirmed w/o divulging name&address. Location for shipping costs & sales takes can be provided w/o divulging name&address

The AADS Policy & Practices consistency writeup is available at http://www.garlic.com/~lynn/

several of the privacy issues have been discussed previously on various mailing lists and are selected postings are also archived at http://www.garlic.com/~lynn/

QC Bio-info leak?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: QC Bio-info leak?
note in the AADS strawman case ... the fingerprint sensor can be configured on the card and it used to activate the card ... in-place of PIN activation (with bio information never appearing in the infrastructure).

the AADS w/PIN activation was what was announced at BAI this past week (BAI show is sort of the world-wide retail banking equivalent of cebit). the AADS strawman also allows that the authentication function doesn't have to only appear in card formfactor ... that contactless/wireless protocol would allow for formfactor agnostic configurations.

one of the challenges has been use in unfamiliar/unknown POS-like environments

also within X9 ... there has been quite a bit of progress w/X9.84 (Management and Security For The Biometrics Financial Services Industry in conjunction with various world-wide biometric standards organizations.

as alwas ... references at http://www.garlic.com/~lynn/

Anders Rundgren wrote:
All,
I have another question for you smart-card experts.

I believe that biometrics as defined by the current QC-draft (002) will in 99% be used in conjunction with smart cards.

Q: How do you anticipate that the bio-template is going to be protected without also requiring that the RP software is authenticating to the card? The latter will IMO not scale that well.

Or is there another genial solution?

My own solution to the problem is to never put "naked" smart cards in unknown readers, but to have them (or it) in a pesonal security terminal. In my case the mobile phone.

Anders

QC Bio-info leak?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: QC Bio-info leak?
??? not applicable to fingerprint??? ... which part? ... the AADS strawman with on-device fingerprint sensor for activation or x9.84?

in the AADS scenerio the chip can be configured to be formfactor agnostic with contactless/wireless infrastructure. the issue of thumb-reader costs justification then becomes a parameterised risk management issue ... there is some at least one application that justifies having the thumbreader for the device ... or there isn't.

as to x9.84
5.1 fingerprint
5.2 speaker recognition
5.3 eye scanning
5.4 face identification
5.5 hand geometry
5.6 signature verification

QC Bio-info leak?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: Re: QC Bio-info leak?
oh yes, the AADS parameterised risk management is attempting to look at the issues of deploying 50+ year lifetime infrastructures.

simplifying a bit, the public key becomes the serial number of the infrastructure that performs the digital signature. That infrastructure has an overall assessed integrity level and is registered when the public key is registered. Incoming transactions can be authenticated ... and then authorization can be decided, in part, based on the integrity level of the signing infrastructure. Also the integrity level can be downgraded in real time as discoveries are made in the future.

In theory, AADS strawman help reduce the integrity unknowns for doing risk assesement portion of authorization. It is even possible that expensive on-device bio-sensors can reduce the overall aggregate infrastructure expenses by 1) reducing risk inaccuracies and 2) eliminating cycles currently being spent in risk assesement things like expensive neural net applications.

Of course, the implication is that reasonable device activation bio-sensors can have higher integrity properties than other device activation methodologies.

Debit card fraud in Canada

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: cryptography@xxxxxxxx
Subject: Re: Debit card fraud in Canada
The combined press release last week at BAI (something like cebit for the world retail banking industry) ... specifies AADS/X9.59 digital signing.

The AADS strawman proposes an online paramerterized risk management infrastructure that can be software, hardware, bin-activated hardware, bio-sensor activated hardware, etc (i.e. integrity level of the compartment doing the digital signing). The issue isn't that the chip enables offline ... but that a chip with various characteristics can improve the integrity of online (non-face-to-face) transactions.

misc. references.


http://internetcouncil.nacha.org/
http://www.garlic.com/~lynn/

and specific ...


http://www.garlic.com/~lynn/99.html#224
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3

At 12:12 PM 12/13/99, David Honig wrote:
At 10:49 AM 12/13/99 -0500, Steven M. Bellovin wrote:
>true for credit cards?  If so, a simple visual recorder -- already used by
>other thieves -- might suffice, and all the tamper-resistance in the world
>won't help.  Crypto, in other words, doesn't protect you if the attack is on
>the crypto endpoint or on the cleartext.
Wouldn't a thumbprint reader on the card (to authenticate the meat to the smartcard) be a tougher thing to shoulder surf? Does raise the cost over a PIN.

Aren't there protocols where the exchange can't be replayed, but proof-of-knowledge is demonstrated?

Or would these exchanges require on-line connectivity, thereby defeating the utility of smartcards some?

RFC 2527 Physical Security Controls Question

Refed: **, - **, - **
From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: RE: RFC 2527 Physical Security Controls Question
in the commercial world ... it is almost alwas a cost benefit trade-off ... there are both penetration exploits and denial-of-service exploits.

a financial operation might have assets where management operations yield a couple billion a day. if the operation of the infrastructure is dependent on security features ... then crippling the security infrastructure might disable the ability to perform financial management transactions and result in the significant losses for the duration of the security infrastructure outage.

theft because of security problems not only may put reputation at risk, but may represent a problem in any court &/or litigation. Litigating theft of trade-secrets valued at several billion can be put at risk if security procedures aren't proportional to the value of the trade-secret (it was explained to me as analogous to not having fence around swimming pool and being liable if somebody fell in ... having value of several billion out in the open, of course somebody will steal it ... and it won't really be their fault). claimed value of several billion for trade-secrets may necessitate demonstrating security procedures valued at tens of millions or more ... and have no obvious/known weakness (the bigger the value the higher the fence).

RFC 2527 Physical Security Controls Question

From: Lynn Wheeler
To: ietf-pkix@xxxxxxxx
Subject: RE: RFC 2527 Physical Security Controls Question
one of the X9.59/AADS scenerios is that the public key operation becomes integrated into the infrastructure of the financial transaction. If that infrastructure has spent several hundred million on security & integrity infrastructure ... then all components have to be at the same level of security/integrity or it puts the infrastructure at risk (don't want to introduce new risk and failure modes).

That somewhat reverses the question ... rather than how much has to be spent on the PKI specific implementation ... it becomes all components have to meet same minimum integrity/security requirements; that goes for both availability (denial of service attacks) as well as compromise (& ability to then do fraudulent transactions).

For some infrastructures, the security/integrity infrastructure may only represent thousands of dollars ... while some commercial operations the security/integrity infrastructure may represent hundreds of millions.

So if public key becomes integral to the core operation (say on a transaction by transaction basis) ... then its associated infrastructure has to at least meet the requirements of that infrastructure (w/o introducing new risk and failure modes).

Furthermore, there may be situations were there is no level of liability & insurance that would make any kind of trusted 3rd parties acceptable

The other issue not to be overlooked ... is that one of the biggest threats to (at least) commercial operations are insiders. Some of the human factors issues may change when only hundreds of billions of dollars are at stake.

Digital Commerce Trivia Questions

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: Digital Commerce Trivia Questions
In the following reference

http://www.garlic.com/~lynn/95.html#13

which two people left and became part of small startup in Menlo Park where their job was to implement something called a commerce server & do digital commerce?

Later the startup changed its name and moved to Mountain View. From what company did they acquire the rights to their new name?

For help on using this list (especially unsubscribing), send a message to "dcsb-request@xxxxxxxx" with one line of text: "help".

Killer PKI Applications

Refed: **, - **, - **
From: Lynn Wheeler
To: Peter Cassidy <pcassidy@xxxxxxxx>
cc: dcsb@xxxxxxxx, tbtf-irregulars@xxxxxxxx, cryptography@xxxxxxxx
Subject: Re: Killer PKI Applications
the original design point for much of PKI was distributed credentials for non-face-to-face, offline, electronic ... i.e. parties that had no prior business relationship and at the moment performing authentication function the relying party wasn't online (analogous to letters of credit in the days of sailing ships long before there was electronic connectivity).

frequently online authentication provides higher quality, specifically targeted and more timely information that could be available with a generalized credential created sometime in the past.

Some trade-offs are the descreased cost of offline vis-a-vis online authentication transaction and the reduced quality and/or timelyness of the information (stale vis-a-vis current). Online costs are drastically dropping as internet and related technologies become pervasive.

So traditional PKI opportunity would appear to be 1) authentication circumstances involving volume costs that have to come in below the dropping online costs (but can still cover the cost of a PKI infrastructure), 2) authentication circumstances &/or transactions that aren't dependent on timely information, and 3) wouldn't require a combination of offline & online (since an online authentication operation can always subsum any of the offline pieces, eliminating duplication of infrastructures).

Majority of existing e-commerce paradigms involve parties with 1) either direct prior relationship or indirect prior relationship thru some financial institution, 2) account-based timely &/or aggregated nformation, and 3) online operation.

Into such an environment, PKI needs to find a thread between the existing paradigms that doesn't require online access &/or account-based timely/aggregated information between parties with no prior relationship.
Peter Cassidy on 01/10/2000 03:08:00 PM
To:   dcsb@xxxxxxxx
cc:   tbtf-irregulars@xxxxxxxx, cryptography@xxxxxxxx
Subject: Killer PKI Applications

Friends,

I am engaged in an expansive and challenging authoring assignment regarding PKI's rationale in the large e-commerce plexus. I'm casting about for ideas on the killer PKI application. I'd like to hear any ideas - however wild or domesticated - in this space. I can repay all kindnesses with beer and whatever appreciations that providence provides I can bestow in the future.
Regards and thanks,
Peter
617 491 2952

Killer PKI Applications

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: bram <bram@xxxxxxxx%gt;
cc: Peter Cassidy <pcassidy@xxxxxxxx%gt;, dcsb@xxxxxxxx,
    tbtf-irregulars@xxxxxxxx, cryptography@xxxxxxxx
Subject: Re: Killer PKI Applications
digital signature enhanced radius (for ISP access authentication, i.e. replacing the password with public key in the authentication database and replacing the password with digital signature on authentication transactions) and in-coming address spoof filtering at ISPs (similar to intranet address spoof filtering for packets coming in from the internet, the ISPs would do address spoof filtering on packets coming into the internet from their customers) would go a long way for addressing a lot attacks (w/o requiring PKI).

then for things like denial-of-service attacks (w/o address spoofing) ... account-based infrastructures would still use account-based public key transactions. In the case of boundary pre-filtering for things like denial-of-service attacks ... there is still trade-off with ASN.1 decoding & public key ops that are still computationally intensive ... & can be greater than TPC-C (for most of the current e-commerce transactions there would still have account-based authentication processing ... boundary pre-filtering represents duplication of effort & could lead to faster resource exhaustion).

It is likely then that a lot of the non-addresses-spoofed attacks would be from compromised machines (given ISP authentication & incoming packet address spoof filtering by ISPs).

Part of the issue is that almost all current e-commerce is transactional account-based paradigm (because of requirements for information timeleness and/or information aggregation). Part of the PKI design point/advantage is targeted to peer-to-peer, anarchy, offline, lacking any account infrastructures.

Work on compromised machine exploits still has quite of bit of work to do and PKI might play in program execution authentication ... say next generation of virus checkers also check for valid program/executable digital signatures. Even then there is a design trade-off between having the visus checker include a (account) table of acceptable public-keys vis-a-vis each program having an appended certificate in addition to the digital signature ... and the virus checker only having a table of CA public keys. Does the user want to pass approval on only the list of trusted CAs or does the user want to pass approval on each individual developer's public key? Once the user decides not to trust the CA as to whether programs from individual vendors are to be accepted ... then the user creates their own table of acceptable public keys (not relying on the CA/PKI trust infrastructure).
From: bram on 01/11/2000 10:41:32 AM
To: lynn.wheeler@xxxxxxxx
cc: Peter Cassidy <pcassidy@xxxxxxxx>, dcsb@xxxxxxxx,
    tbtf-irregulars@xxxxxxxx, cryptography@xxxxxxxx
Subject: Re: Killer PKI Applications

The first thing something needs to be a killer application is to be an application. The problem with PKI is that it isn't an application, it's a system. A killer app needs to have a very specific purpose, and needs a very immediate motivating factor for it's use. Think web browser.

I'm more than a little bit skeptical that the world has much use for PKI just yet. PKI is useful for stopping active attacks, but right now almost everything on the internet is subject to passive attacks. Fix the first problem first, only then will it become clear how to solve the second problem.

-Bram

Killer PKI Applications

From: Lynn Wheeler
To: "Bill la Forge" <b.laforge@xxxxxxxx>
cc: "bram" <bram@xxxxxxxx>, "Peter Cassidy" <pcassidy@xxxxxxxx%gt;,
    dcsb@xxxxxxxx, tbtf-irregulars@xxxxxxxx, cryptography@xxxxxxxx
Subject: Re: Killer PKI Applications
the other problem with the CA approach is what is the CA certifying. Are they purely certifying the name of the company producing software applications ... or are they certifying every application that each software company produces. If I have to decide every company that I'm willing to accept software from ... then I've gone to a per company process that can be done with online authority and I'm maintaining a list of per company-based accpetable software sources. I don't need & am not using a hiearchical CA-based trust infrastructure (possibly other than in a purely contrived manner).

For the CA-based trust infrastructure to work for this scenerio ... the CA needs to be asserting the trust/quality/integrity of applications produced by each software company (so that I only need to record CA-level trust decisions) ... once I need to record vendor-level trust decisions then I've truncated any trust hierachy (embodied by a CA which then becomes redundant and superfluous).

From: "Bill la Forge" on 01/11/2000 01:19:34 PM
To: lynn.wheeler@xxxxxxxx, "bram" <bram@xxxxxxxx>
cc:   "Peter Cassidy" <pcassidy@xxxxxxxx>, dcsb@xxxxxxxx,
      tbtf-irregulars@xxxxxxxx, cryptography@xxxxxxxx
Subject:  Re: Killer PKI Applications
Once the user decides not to trust the CA as to whether programs from
individual vendors are to be accepted ... then the user creates their
own table of acceptable public keys (not relying on the CA/PKI trust
infrastructure).
Part of the problem with taking the CA approach is in dealing with multiple roots. We've drilled down on this problem a few times and having a signed list of acceptable keys is a solution that keeps coming back up.

Frankly, I think this is an area where XML is going to play quite well. And I'm delighted with the latest draft on XML-based digital signatures:
http://www.w3.org/TR/xmldsig-core/

Bill la Forge, CTO
JXML, Inc.

Killer PKI Applications

From: Lynn Wheeler
To: Randy Witlicki <randy.witlicki@xxxxxxxx>
cc: Peter Cassidy <pcassidy@xxxxxxxx>, dcsb@xxxxxxxx,
    tbtf-irregulars@xxxxxxxx, cryptography@xxxxxxxx
Subject: Re: Killer PKI Applications
Claim is that the draft X9.59 financial industry standard (for all retail payments) could provide the level of integrity that would justify better than card/consumer present rates; i.e. the level of the integrity of the transaction is at least card present ... and the characteristic of X9.59 makes the account number pretty much worthless in non-signed transactions (i.e. even if every account number from X9.59 transactions were kept at a merchant server database ... and that database was compromised, the information could not be used for fraudulant transactions).

One of the charters to the X9A10 working group for X9.59 was to preserve the integrity of the financial infrastructure with only a digital signature and be applicable to all retail based payments. The X9.59 mapping to existing payment card infrastructures, while relying on digital signatures does not rely on certificates and/or associated PKI/CA infrastructures.

For more information see various references at:

http://www.garlic.com/~lynn/
From: Randy Witlicki on 01/11/2000 04:15:07 PM
To: Peter Cassidy <pcassidy@xxxxxxxx>, dcsb@xxxxxxxx,
    tbtf-irregulars@xxxxxxxx, cryptography@xxxxxxxx
Subject:  Re: Killer PKI Applications

The killer app should make somebody very rich.
Perhaps where the consumer can make an online purchase, same as now with an SSL browser link, but they are using a credit card from "Hettinga National Bank" where the consumer gets a 1/2 percent rebate and the merchant gets charged 1/2 percent less than other credit cards (to encourage the merchant to recommend Hettinga National Bank to their customers).
This would likely require disintermediation of of various finanacial processing links, maybe PKI, and perhaps even Digital Bearer Certificates.
In this case, PKI is probably a Business-to-Business backend tool.
Or have I been mis-reading Bob's cogitating and rants ?
- Randy

Killer PKI Applications

From: Lynn Wheeler
To: Greg Broiles <gbroiles@xxxxxxxx>
cc: "Bill la Forge" <b.laforge@xxxxxxxx>,
    "bram" <bram@xxxxxxxx>,
    "Peter Cassidy" <pcassidy@xxxxxxxx>,
    dcsb@xxxxxxxx, tbtf-irregulars@xxxxxxxx, cryptography@xxxxxxxx
Subject: Re: Killer PKI Applications
your comments don't appear to be inconsistent with Jane Winn's writings on PKIs

for instance her paper:

The Hedgehog and the Fox: Distinguishing Public and Private Sector Approaches to Managing Risk for Internet Transactions, 51 ABA Administrative Law Review 955 (1999)

This article argues that much recent and proposed electronic commerce legislation is based on flawed assumptions regarding risk management and the practical utility of current electronic commerce technologies. Such flawed legislation would produce a loss allocation system that would undermine incentives that currently exist to improve the technological infrastructure of Internet commerce. This paper was presented at a conference at American University in March 1999.


http://www.smu.edu/~jwinn/hedgehogfox.htm
!! NOTE: moved to: !!
http://www.law.washington.edu/Faculty/Winn/Publications/The%20Hedgehog.htm

or other papers at her site:


http://www.smu.edu/~jwinn/
!! NOTE: moved to: !!
http://www.law.washington.edu/Faculty/Winn/
From: Greg Broiles on 01/12/2000 01:47:04 AM
To: lynn.wheeler@xxxxxxxx
cc: "bram" <bram@xxxxxxxx>,
    "Peter Cassidy" <pcassidy@xxxxxxxx>,
    dcsb@xxxxxxxx, tbtf-irregulars@xxxxxxxx, cryptography@xxxxxxxx
Subject:  Re: Killer PKI Applications

While this would certainly be an interesting goal to achieve, I think it's worth remembering that current software industry practice is for the software publishers themselves to disclaim all or almost all warranties regarding the performance of their software or its lack of errors .. so you're asking CA's to guarantee something that publishers themselves don't, at present.

javasoft SET - NO!

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: Budi Wiyono <budiw@xxxxxxxx.id>,
    "set-discuss@xxxxxxxx" <set-discuss@xxxxxxxx>
Subject: Re: javasoft SET - NO!
there are numerous examples of all sorts of new things that never succeded in the marketplace for one reason or another. I ran across article at PIRP (www.pirp.harvard.edu) not too long about about payment infrastructures that didn't make it .... I believe one was a public/private key effort in UK in the 80s that never caught on because of one reason or another.

There are also related examples in related areas ... US federal government in the early '90s was still mandating GOSIP and that TCP/IP would not be used.

One of the issues about payments on the internet is protection of the associated information both while "in-flight" as well as "at-rest". Original "e-commerce" methodology and still the dominant method is SSL for "in-flight" protection (I was slightly involved with this having worked with small startup in menlo park on implementing payments for something called commerce server ... random reference:

http://www.garlic.com/~lynn/aadsmore.htm#dctriv

Slow adaption frequently is an issue with intrenched methods that already satisfy (at least most of) the business requirements. Current deployed infrastructure caught on very quickly.

Most of the payment exploits we've been hearing about recently are "at-rest" exploits (i.e. things in the news are about exploits involving "at-rest" information ... not exploits of "in-flight" information).

slightly related reference:


http://lists.commerce.net/archives/ansi-epay/200001/msg00008.html
&
http://www.garlic.com/~lynn/ansiepay.htm#theory
http://www.garlic.com/~lynn/ansiepay.htm#privacy
http://www.garlic.com/~lynn/aepay3.htm#x959risk2

re:The Law of Digital Cash

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: dcsb@xxxxxxxx
Subject: re:The Law of Digital Cash
one of the things that I've heard in the past was european central bank view of many of the electronic cash/stored value instruments floating around. Supposedly these instruments are somewhat currently viewed as "float" ... money is transferred to the electronic cash instrument, debited from the bank account, and bank no longer has to pay interest on the transferred value (seems like the float aspect may represent the largest value proposition of these electronic cash instruments). In any case, the position attributed to european central banks was that they would tolerate the instruments & allow the float aspect to help subsidize their establishment in the market place ... but once established ... regulations would be jmplemented requiring interest to be paid on unspent electronic cash.

For help on using this list (especially unsubscribing), send a message to "dcsb-request@xxxxxxxx" with one line of text: "help".

Smartcard anonymity patents

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
To: cypherpunks@xxxxxxxx, cryptography@xxxxxxxx
Subject: Re: Smartcard anonymity patents
current magstripe cards in US have names ... whether they are used or not ... allow relying party to cross-check name on card with forms of identification hopefully containing the same name.

One economic model has chipcards in europe for offline transactions as being more cost effective ... versus magstripe in US doing online transactions ... i.e. telco cost difference in europe vis-a-vis US offset the cost difference between chipcards and magstripe cards. However, much of the world is transitioning to cost-effective online infrastructure ... changing some of the chip/telco cost tradeoffs that had been made in the past.

The play that chipcards do have (even in the face of declining online costs) is 1) chip costs decreasing and 2) migration to more & more non-face-to-face. electronic transactions. chipcards can provide a higher level of integrity and lower risk & fraud compared to magstripe (even in online transactions ... and especially in non-face-to-face online). The cost/benefit play for chips in such an environment is the increased cost of chips vis-a-vis any reduced fraud & risk from using chipcards (compared to existing magstripe fraud & risk).

It is possible in X9.59 digitally signed financial transactions ... to enhance privacy by removing the requirement for name/address/etc in authenticating the transaction ... but neutral from the standpoint of anonymity; i.e. the rest of the infrastructure business process determines whether the overall transaction is anonymous (body of the transaction doesn't contain identification information ... but the business processes could associate identity as part of processing the transaction). In a payment card scenario ... X9.59 would provide a tight authenticating binding between the payment transaction and the account; whether or not the bank provides a binding between the account and a person becomes a business process outside of authenticating the transaction.

The identical transaction protocol works also in the Business<->Employee scenario ... there can be a tight binding between a transaction something like an employee serial number. Then it is up to the business what processes are used for doing a tight between the employee serial number and the employee.

biometrics and electronic signatures

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: Re: biometrics and electronic signatures
one of the issues of biometrics for authentication is that the biometric data tends to be like a long pin/password (aka shared-secret) ... on one hand, you don't have the problem remembering it ... but on the other hand ... it is very hard to change it once it becomes compromised.

biometrics have tended to be situations involving secure sensors possibly under some sort of observation (i.e. guardpost where there is only a question of is the person actually who they claim to be ... ;little question that the data is coming from a valid biometric source).

non-face-to-face internet w/o secure sensors and secure environment becomes more problematical with the possibility that your biometric pin/password becomes compromised ... allowing it to be generated electronically by other individuals (and difficult to change in the event of a compromise).

since it is so difficult to change biomertic pin/password &/or have different biometric pin/password ... biometric have tended to be closed systems (i.e. security issues about using the same pin/password in multiple different administrative security domains with different requirements).

For open internet environments, a special case is a public/private key digital signature card ... owned by the individual and instead of a standard numeric pin/password for card activation ... biometric data is used for card activation. then the "closed" system is just between the individual and their card. A card compromised can still be dealt with by invalidating the current card and getting a new card.

The person's digital signature is their public/private key (whether it is a pin activated card or a biometric activated card) but parameterised risk management comes into play ... i.e. risk, fraud, & integrity parameters are different for (short) pin activated card and biometric activated card.

misc. ref at:

http://www.garlic.com/~lynn/

biometrics and electronic signatures

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
To: DIGSIG@xxxxxxxx
Subject: Re: biometrics and electronic signatures
oh yes ...

there was thread on bio-info leak on ietf-pkix list ... some of the postings

http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3

A proposal for secure videoconferencing and video messaging over the Internet

From: Lynn Wheeler
To: coderpunks@xxxxxxxx, cryptography@xxxxxxxx
Subject: Re: A proposal for secure videoconferencing and video messaging over the Internet
we've had some of this discussion related to X9.59, namely that SSL verifies that the URL used and the certificate DNS info somewhat correspond. one problem is that many people don't necessarily arrive at a web site by actually typing the URL ... so provided URLs are one method of attack. The other is that certificate DNS information is typically verified by the certification authority contacting the DNS authority. Issues with DNS hijacking (i do dns hijack of xyz.com and then apply for certificate for xyz.com) and other exploits can be addressed with DNS public-key (aka reliable DNS infrastructure) which could make SSL certificates redundant and superfluous (i.e. one explaination is that SSL certificates exist because DNS is unreliable ... but since the certification is dependent on reliable DNS ... and a reliable DNS can be achieved with addition of public keys to the DNS information ... then it becames possible ot obtain public keys directly from the reliable DNS authority at the same time the other DNS information is obtained).

the other part, is X9.59 requires that electronic payments transactions are electronically signed .... so only a specific payment might be subverted (supplying the wrong "pay-to" value) ... but additional payments could not be done with the information. Note however, the wrong "pay-to" value still needs to be a valid merchant identifiier in the payment infrastructure.

The issue then becomes that the URL was supplied to the browser by a trusted method & a reliable DNS is available with some sort of public key authentication (whether with public key directly from reliable DNS .... or circuitous route via a certificate which came from a certification authority which verified with a reliable DNS).

misc. URLs:

http://www.garlic.com/~lynn/aepay4.htm
http://www.garlic.com/~lynn/

there are still some misc.; issues where the wrong "pay-to" field is supplied for a signed payment transaction (say a hacked web site).

pieces for this opportunity include are at the international/iso level for a global merchant identifier (effectively a "pay-to" value). A trade-group could be setup that provided a merchant-id/publickey binding.

Even simpler yet, since a reliable DNS is already a requirement, it would be possible to register both a public key (to address issues like DNS hijacking) and a merchant-id. The DNS information, merchant public key, and optional merchant-id (i.e. "pay-to" in a payment transaction) could then be provided as part of a standard DNS operation (further illustrating certificates as being redundant and superfluous in AADS-like public key environments).

There are still some open issues regarding trusted path for supplying URL information and trusted browsers. Obviously trusted browswer can include things like does the transaction the user "sees" being the same as the transaction the user authorizes/signs .... but then even simple aspects of existing SSL are also dependent on trusted browser (i.e. the browser actually checks for valid binding, sets up a private SSL session, etc).

Steve Reid wrote:
To be fair, the sort of attack I described could work against SSL too. Certificates can confirm that www.example.com is who you are contacting, but certificates can't stop them from making their web site look just like www.example.net's and duping people into giving payment information to the wrong people. I think it would work especially well against a videoconferencing system though, because there is a certain trust inherent in face-to-face communications.

Client-side revocation checking capability

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
To: Dennis Glatting <dennis.glatting@xxxxxxxx>
cc: Bob Jueneman <bjueneman@xxxxxxxx>, juancarlos.perez@xxxxxxxx,
    ietf-pkix@xxxxxxxx, anders.rundgren@xxxxxxxx
Subject: Re: Client-side revocation checking capability
it goes further than that ... since the "authority" for which domain name certificates are issued is the domain authority .... it is possible to "poisen" that infrastructure (domain name hijacking) ... apply for a certificate ... have it verified as valid by the domain name infrastructure, and have such a certificate certified as valid.

there are proposals for improving the infrastructure of the domain name infrastructure with digital signatures and public keys .... which addresses both dynamic poisening as well as domain name hijacking types of poisen. Such a trusted DNS infrastructure then could also return the same public key as part of domain name lookup. At that point, existing certificates become redundant and superfluous. In part, the problem of vulnerable DNS infrastructure is not only the dynamic name lookups but also extends to core DNS infrastructure ... which domain name certificates rely on for validating information that goes into a certificate. Addressing the vulnerabilities of the DNS infrastructure (for both dynamic name lookup as well as certification/validating of certificate information) turns out to also make certificates redundant and superfluous.

Dennis Glatting on 08/14/2000 10:56:39 AM


To: Bob Jueneman <bjueneman@xxxxxxxx>
cc: juancarlos.perez@xxxxxxxx, ietf-pkix@xxxxxxxx, anders.rundgren@xxxxxxxx
Subject: Re: Client-side revocation checking capability

I disagree. To access www.amazon.com one uses DNS, which is not secure and often easy to poison. Consequently, mafia.com can redirect some number of browsers by poisoning some number of DNS servers, present a Amazon.COM store front, and use Amazon's cert and private key. If the browser doesn't check for revocation then the consumer is none the wiser, at least for a while.
> Bob
>
>  "Anders Rundgren" 08/12/00 12:02AM
> Juan Carlos,
>
> That on-line checking of server-certificates is not standard in
> browsers is probably beacuse a revocation is not that likely to
> happen.  In case of a key compromize at the VeriSign CA the whole
> world will be notified and in the case of key compromize in a
> web-server no one will know or be notified.  You can steal a
> web-cert+key from a lousy installation (most are) in case you have
> sys-admin rights.  Nothing to do about except tighten up internal
> security.  And if the host-name is no longer valid (the company filed
> for bancruptsy) the server will be taken down some day.
>
> IMO status-checking is only needed (or implementable at least) for
> person-oriented certificates, where you may revoke yourself due to
> loss (of card) or by the company because you got fired.
>
> This is a slightly different answer than you get by asking a typical
> crypto expert but to my knowledge they usually know zilch, nada
> etc. about practical things that may be 100 times more important than
> the cryptologic solurtion.  I.e. as long as there are serious
> practical problems associated with server-certificates, CRLs
> etc. would basically add nothing (but delays).
>
> Regards
> Anders
>

Client-side revocation checking capability

Refed: **, - **, - **, - **
From: Lynn Wheeler
To: Stephen Kent <kent@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: Client-side revocation checking capability
actually I believe in CERTS containing some amount of "account" data that can be used in offline environments when access to the account record is not available. In that sense, for business applications that are account record oriented, CERTS can provide a stale (possibly subset) of what might appear in the business account record.

however, in an online model where a transaction or message has to "hit" the account record in any case, it is possible to obtain the public key from the "master" in the account record ... w/o having to bother with an account record substitute represented by a CERT (i.e. a certification authority has a master account record someplace with most/all information that went into a CERT ... along with audit trails and other business requirements that are ordinary part of business account transaction).

In the DNS case, lack of trusted DNS is even a problem for certification authorities issueing SSL certificates ... since the domain name "authority" that the certificationa authority has to reference to validate the information to put in a CERT ... is the same untrusted DNS infrastructure (as some of the comments about domain name hijacking represents).

Part of the solution for created a trusting domain name "authority" operation is to add public keys and digital signature authentication to DNS operation. That would even closes integrity "holes" that SSL certificates have because the authority for the domain information that goes into the SSL certificates can now be trusted.

My observation is just that with the addition of public keys to domain name infrastructure ... then the DNS operation not only "hits" an online account record ... but also one that may include the trusted public key (part of making the entry trusted and harder to hijack). DNS already supports returning all sorts of information in addition to host names to ip address mapping ... so the ability of returning such public keys as part of a trusted DNS operation is straight forward.

At this point, all DNS operations now could provide both trusted address mapping and public key binding as part of each online operation. Such a facility would then make the majority of existing server-side SSL certificates redundant and superfluous.

The side observation is there is a requirement for such a trusted DNS infrastructure ... just to improve the integrity of existing server-side SSL certificates (i.e. problem with hijacking host name and then obtaining a SSL certificate since the certification authority has to resort to using the DNS infrastructure as the authoritative entity for validating DNS information). But addressing that requirement then also makes the need for such servier-side SSL certificates redundant and superfluous.

Stephen Kent on 08/15/2000 01:30:47 PM


To: Lynn Wheeler@xxxxxxxx
cc: ietf-pkix@xxxxxxxx
Subject: Re: Client-side revocation checking capability

Lynn,

I agree that a PKI based on the DNS would be a great benefit to the Internet. Now that VeriSIgn has bought NSI, the likelihood of creating such a PKI seems remote, as it would create a decentralized PKI that would challenge the VeriSign TTP model.

DNSSEC makes use of non-certificate constructs (for understandable reasons having to do with DNS security details), that are not really a good substitute for real certs. Of course, you're a strong believer in no certs at all, so I'm not surprised that you would find DNSSEC a suitable alternative all by itself :-).

Steve

President Clinton digital signing

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 08/24/2000 07:34 AM
To: Tom Strickland <tstrickland@xxxxxxxx>
cc: Liaquat Khan <liaquat.khan@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: President Clinton digital signing
a number of financial infrastructures not only need real-time status ... but also things like real time inforatmion, no single point of failrues and some even five nines availability. also looking at it from a transaction flow aspect, the transaction has to hit the account record (for other real time informaiton reasons ... like account balance) ... and involve an infrastructure that have existing business infrastructures with both authentication and authorization. For these types of financial infrastructures ... they need to control their own infrastructure including things like RAs ... where they do the public key registration in the account record ... and returning a copy of relying-party only certificate to the account holder (for liability and privacy reasons).

The interesting thing is that these protocols appends a copy of the certificate to a signed message that is sent to the financial institution ... when the financial institution has the original of the certificate in the account record (an account record that has to be read in any case to perform the financial ttransaction).

The simpler process is to recognize that it is redundant and superfluous to return a copy of a certificate (appended to every signed message) sent to a financial institution, a financial insitution that will be reading a record containing the original of the certificate. Since the master account record with not only real-time status as well real-time information is being read as part of executing the operation ... it not only eliminates the extraneous transmission of appended certificates, eliminates requirements for both CRL & OCSP checking, minimizes points of failures, and improves availability.

misc. refs:

http://www.garlic.com/~lynn/99.html#71
http://www.garlic.com/~lynn/99.html#128
http://www.garlic.com/~lynn/ansiepay.htm#aadsnew2
http://www.garlic.com/~lynn/aepay2.htm#position

mapping of the draft x9.59 financial standard to existing online networks:

http://www.garlic.com/~lynn/8583flow.htm

Tom Strickland on 08/23/2000 05:31:12 AM
Example: If a company does not have a requirement for current information, a CRL is sufficient. If a company requires real time data (i.e. a bank or government) due to high value transactions or security, then I would highly recommend OCSP. The risk is if you use CRLs for the latter, the company may get a false sense of security believing their "high value" transactions are guarded by real time data. If the batch CRL is latent, you may continue processing utilizing old data. The risk is a cert believed to be revoked may still be considered good in the system exposing the company to potential fraud or negligence.

In an OCSP environment, if you must trust real time data and someone executes a DoS attack, the responder may slow down or worst case, stop working. This is an added value because I would rather slow down or stop processing than to rely on old data. The risk here is slower response time but guaranteed accurate information.

"request certificate"

From: Lynn Wheeler
Date: 08/24/2000 10:12 AM
To: Tai <tai@xxxxxxxx>
cc: cert-talk@xxxxxxxx
Subject: Re: "request certificate"
the most prevalent authentication mechanism on the internet has been radius

http://www.garlic.com/~lynn/aepay4.htm#rfc2807b
http://www.garlic.com/~lynn/aepay4.htm#rfc2807c

general rfc index ... can pick out radius from the terms index

http://www.garlic.com/~lynn/rfcietff.htm

Tai on 07/26/2000 01:14:09 PM
To: cert-talk@xxxxxxxx
Subject: "request certificate"

Hiyas all,

As I understand it, you can put a "request certificate" on a page, when a browsesr hits that page, it'll ask the user for a cert. But can you not require authentication such that a user will only present a cert if he/she/it has one, but if he/she/it doesn't, the page will still come up?

Anyone can point me to some good urls on using certs and general web based authentication mechanisms? Thanx.

-Tai

Client-side revocation checking capability

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/29/2000 8:52:43 PM
To: "David P. Kemp" <dpkemp@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: Client-side revocation checking capability
a relying party presumably executes some protocol initiation, signing validation, certificate validation, etc. after all that is done, the relying party can compare some "bound" information in the certificates with something that the relying party may be assuming and/or expects.

If the relying party is expecting a specific business name ... they could check if the business name in the certificate matches the business name they are expecting. They might also have some expectation as to the due diligence that the certification authority exercised in validating that information (for business names ... possibly checking with D&B).

Now looking at possibly a trivial occurance of relying party checking ... maybe only a trivial 99.99999999999999% of all relying party "checking" currently going on ... it would appear that the most common occurance of a relying party checking something is a SSL relying party checking a domain name. 99.999999999999% of all such checking might not seem like a valid situation to consider.

Now if the most common client-side validation of certificate information (only a trivial 99.9999999999999% of all such checks) involves domain name checking ... then clients might expect that certification authorities would be checking some authority that is involved in registering domain names.

Now, it is possible that certification authorities might check with their local police station with regard to who has registered an internet domain name ... or they could check with D&B ... or they could check with all the agencies in the world which are explicitly not part of registering domain names.

Frequently I've heard reference to one of the reasons for certificates in the SSL protocol is because of weaknesses in the domain name system ... which can be corrected by SSL domain certificates issued by certification authorities ... who may have check with the domain name registration authority as to the validity of the domain name (or on the other hand could have just checked with their local police station as to who owns a particular domain name). A minor issue if the domain name system is weak ... then it also is weak as an authority of certification authorities to check the information that they supposedly need to be correct (but which the domain name infrastructure can't be trusted to verify as correct????).

So some of the proposals are to add public key registration to the domain name process. That makes it harder to hijack domain names and leads to a more trusted domain name system. Given a trusted domain name system with public keys, then the domain name system could return the public key (associated with a domain name) at the same time it returned the IP-address. However, if a trusted domain name system returned a public key as part of the domain name process, then having an SSL domain name certificate with a public key would seem to be redundant and superfluous (at least as far as the trivial SSL case under consideration).

SSL certificates are somewhat a catch-22 ... some believe they exist because of untrusted DNS ... however the SSL certificate certification authorities would appear to be dependant on an untrusted domain name system as the authority for the domain name information that they place in SSL certificates ... creating a trusted DNS with the addition of public keys ... allows the real-time DNS domain name infrastructure to the real time authority of public keys for an SSL protocol as part of the standard domain name process. In this particular scenerio, SSL certificates would appear to be redundant and superfluous (aka it isn't necessary to have a certification authority manufactur a stale certificate with stale bound information ... when a trusted DNS is providing real-time information).

That doesn't say that all certificates with public keys are redundant and superfluous ... just the apparent most common scenerio ... at least in terms of relying party/clients validating information ... possibly only a trivial 99.99999999999% of the cases (the SSL scenario). If the relying party isn't doing something on the internet and requires little or no IP services (including DNS) ... but still needs some authentication process, then certificates could address the opportunity.

One could do SSL with an ip-address ... rather than a domain name ... and bypass the (real time) domain name system alltogether and rely on stale information in manufactured certificates. Hopefully the certification authority would be checking some internet ip-address authority (rather than the local police station).

"David P. Kemp" on 08/28/2000 04:41:45 PM
To:   ietf-pkix@xxxxxxxx
Subject:  Re: Client-side revocation checking capability
Reminds me of the blurb for a new fall TV series:

Student: "You mean we should go online [to check the facts on a murder]?"

Reporter: "No, I mean you should put on your socks and shoes and walk down to the police station."

A CA doesn't have to resort to using DNS to validate the legitimacy of requests for certificates containing DNS names. In fact, there is no point in doing so - DNS maps names to IP addresses, certificates map names to public keys. Finding a DNS record, hijacked or not, doesn't give a CA any assurance that a public key belongs to the owner of the name.

Certs-by-email are cute toys for users to play with, but any merchant using such a cert shouldn't get an "XYZ seal of approval" from any legitimate XYZ auditing organization. The value added by a CA who checks with D&B and WIPO before issuing a server cert is nearly orthogonal to the value added by secure DNS (at least until DNS administrators publish their CPSs). And even if the CA and the DNS used identical identity proofing procedures, independently-issued name-to-key and name-to-IP certificates provide additional assurance. Maybe overkill for some applications, but certainly not redundant and superfluous.

Dave

Client-side revocation checking capability

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/05/2000 08:12 AM
To: "David P. Kemp" <dpkemp@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: Client-side revocation checking capability
some general comments and three example/scenerios

I have not been commenting at all about how you might want the world of certificates to behave.

I've only been making observations and assertions about the trivial case that accounts for 99.9999999999999999999% of the current real world situations where a client compares some information against something in a server certificate (namely an SSL session involving a domain name in a server certificate)

While there may be problems with client browsers checking for domain name in a server certificate for SSL session setup .... then there are problems.

If server certificates can be done some other way, then server certificates can be done some other way. It doesn't negate the comments, observations and assertions about the way the specific trivial case operates, namely the trivial case involving 99.99999999999% of the current activity where clients do something with a server certificates.

The observation is that for the trivial case outlined ... namely the one in the real world today which accounts for 99.9999999999% of where a client is doing something with server certificates (namely SSL and domain names) .... that adding public key for domain name authentication can make that current use of server certificates for the specific case outlined (involving 99.999999999999% of today's activity involving server certificates) redundant and superfluous.

There could be all sorts of non-trivial cases for certificates to which that observation doesn't apply. It was specifically made as an observation for that specific case. These other non-trivial cases ..... which possibly accounts in aggregate for possibly <0.0000000000001% current day server certificate activity.

I believe that public/private keys are about authentication (at least in the digital signature case, things like FIPS186). The SSL use of server certificates (the trivial case that currently accounts for 99.999999999999% of current real world activity involving clients doing something with server certificates).

DNS is both about availability as well as trust, not only is the information readily available, but can the information also be trusted. One way of improving the trust in DNS information is the shortcut that SSL protocol took with SSL server certificates. Another way in improving the trust in the DNS information is by adding public keys (and digital signatures) to DNS as part of an authentication feature.

The issue isn't that the domain name to IP-address operation isn't necessary. The observation is that when registering a domain name there is already quite a bit of information that is registered (some people may have forgotten but there are things like name/address/phone# for technical contact, administrative contact, billing contact ... don't forget they need to bill somebody for the registration). The further observation is that there are currently integrity problems with the current domain name infrastructure and trust is a big issue here. Adding public keys to the current registration process is actually quite a small incremental increase (at least for ECC keys) in the amount of data. The percentage increase in the process for registering public keys isn't large. Given all the issues about trademarks with respect to domain names .... the administrative load is increasing totally independant of whether public keys are being registerred. Furthermore, because of the issues like domain name hijacking, administrative load is also increasing for better authenticating that only the domain name owner is allowed to make changes.

The registration and use of public keys for domain name infrastructure authentication can actually reduce the increases in administrative load.

The domain name infrastructure is very much about authentication and trust ... not just about mapping a domain name to an ip-address. Some people may only have limited experience with a small subset of the domain name instructure ... namely the resolved operation that returns an ip-address for a given domain or host name. However there are huge issues involving quite a bit of administrative workload involving who owns domain names and who is allowed to operate on information associated with domain names. No realizing that is a very myopic & narrow view of how the current internet and web environment actually functions on a day to day basis. The domain name infrastructure very much has to know that the "domain name" owner is the entity that is allowed to change, update, &/or delete information associated with a domain name. Nominally such "knowing" involves some sort of authentication function. Registering passwords &/or PINs is one way for providing for authentication. I think that many people would agree that registering public keys and using digital signatures can be a much better authentication process (than passwords or PINs).

Now, there might be an issue of adding a public key to all current standard DNS responses (which might just involve a single IP-address). Standard DNS today allows for queries that return information in additon to host ip-address. I contend that modifying existing SSL protocol to do a DNS query for both an IP-address and a public key .... would represent an overall reduction in SSL protocol web bandwidth used, server processing and client processing (aka server doesn't transmit one or more certificates, client doesn't validate one or more certificates in order to decide if it can use the server's public key).

One of the assertion is that while the SSL server certificates were to address a trust deficiency in the DNS infrastructure ..... those same SSL server certificates are dependant on trusting the DNS infrastructure as the final authority on who owns a domain name.; That, in fact (because of issues like domain name hijacking) that even SSL server certificates would benefit from improving the trust in the DNS infrastructure. One way of improving trust in the DNS infrastructure is to add authentication (via public keys) to various DNS business processes. The assertion is that if public keys are added to that infrastructure ... then that makes public keys & domain names in SSL server certificates redundant and superfluous. Furthermore, if it is no longer necessary to have SSL server certificates for public keys and domain names, then the SSL server certificates and also redundant and superfluous.

I've still not commented about any of the non-trivial cases of server certificates that possibly represent <0.0000000000001% of the total current activity where a client is checking some information in a server certificate. I've tried to restrict myself purely to the trivial case which represents 99.999999999999% of all current activity where a client is checking some information in a server certificate.

I've tried to not comment anything about general application security or PKI or whatever. I've tried to restrict myself purely to the trivial case which represents 99.99999999999% of all current activity where a client is check some information in a server certificate.

For that particular trivial case, I've asserted that adding public keys to DNS for authentication (within FIPS186), then the trust in the DNS information can be improved (and make it much more difficult to do things like hijack a domain name). Furthermore the server certificates for the trivial case involving 99.9999999999% of all current activity where a client is checking some information (i.e. domain name in an ssl certificate) are also at risk if domain name is hijacked (i.e. I can hijack a domain name and then get an SSL certificate for that domain name). Therefor these SSL certificate infrastructures also need the trust in the DNS infrastructure improved. My observation that addressing the DNS infrastructure trust issue with public keys and authentication ... in order to remove the risk to the SSL certificate infrastructure also can make the SSL certificate infrastructure redundant and superfluous.

Again, I'm not making any general observations about PKIs or PKIXs. I'm not making any observations about the current non-trivial cases involving server certificates that account for <0.00000000000001% of the current situations where clients are currently checking some information in a server certificate. I'm only making the observations about the trivial case which accounts for 99.9999999999999999% of the current situations wehre clients are currently checking some information in a server certificate.

I'm not making any suggestions about combining DNS and PKI. I'm making suggestion that public keys can be added to domain name registration for authentication purposes (the person that registers the domain name and the ip-address(es) can operate on the entry). The observation is that the registration of a public key when the domain name is registered can improve the trust in the DNS infrastructure by authentication operations. Furthermore, DNS can provide (in real time) all information registered for domain name entry ... to whatever decree of trust that DNS information is trusted. If the registered information includes a public key ... then that public key can be provided to clients at the same time it provides any other registered information (like IP-address mapping for a domain name).

To the degree that the domain name can be trusted .... the public key can be trusted to the same degree.

!!!!!!!!! To re-iterate, the following discussion applies only to the trivial case involving 99.9999999999999999% of the current situations where a client is checking some information in a server certificate (namely the SSL protocol involving the domain name SSL server certificate).

!!!!!!!!! The following discussion does not (necessarily) apply to any non-trivial cases involving <0.00000000000001% of the current situations where a client is checking some information in a server certificate (including any non-SSL server certificate for merchant/company names).

=================

scenerio/example 1

So specifically for the SSL server certificate case, if a public key is needed for authenticating a server at a specific domain name:

A CA can get a request to issue a domain name SSL server certificate

A CA can contact the domain name registration authority as to the validity of the domain name ownership

The degree that a domain name SSL server certificate can be trusted is to the degree that the domain name registration authority can be trusted

Assuming that the domain name registration authority can fix many of its trust issues with authentication, digital signatures & public keys

Then the assertion is that the trust in the domain name SSL server certificate can be no better than the trust in the domain name registration authority public keys

If the trust in the domain name SSL server certificate can be no better than the trust in the domain name registration authority public keys, clients can use "real-time" domain name registration authority public keys in lieu of domain name SSL server certificate public keys

If 1) domain name SSL server certificate public keys are at the same trust level as the domain name registration authority public keys and 2) the domain name registration public keys are available and updated in real time, while 3) the domain name SSL server certificates are manufactured at some period in the past and can be stale or incorrect, then I contend that the domain name registration public keys actually are actually more trusted because of the real-time availability and update.

Showing that the domain name registration public keys are more trusted than the domain name SSL server certificates and the domain name SSL server certificate public keys also shows that the domain name SSL server certificate public keys are redundant and superfluous. If the domain name SSL server certificate public keys are redundant and superfluous then the domain name SSL server certificates are redudant and superfluous (for the specific trivial case under discussion which accounts for 99.999999999999% of current real world cases where client is checking some information in a server certificate).

=================

scenerio/example #2

so now lets look at adding a CA PKI to the domain name infrastructure to authenticating domain name owners for domain name transactions. this is going to be similar to relying-party-only PKI used by various banks (for liability and privacy reasons.

1) domain name infrastructure sets up a CA PKI that registers domain name owner public keys as part of domain name registration.

2) the CA PKI is setup to manufactur an sign domain name infrastructure relying party certificate, basically the name is the domain name bound to the domain name owner's public key and whatever other domain name related information that the infrastructure wishes to put in the certificate (possibly ip-address).

3) The CA PKI stores the original of the certificate in the associated domain name entry in compressed form (i.e. un-encoded, non-unique information removed, etc)

4) The CA PKI returns a copy of the certificate to the domain name owner.

5) The domain name owner a) generates domain name owner transactions, b) signs the transactions, c) sends the transaction and signature with a copy of the certificate appended to the domain name infrastructure

6) For efficiency sakes, the appended certificate is compressed, all fields known to already be in the possession of the relying party are removed. Since the relying party already possesses the original manufactured certificate (and the domain name owner only has a copy of that same certificate), the appended certificate is compressed to zero bytes.

7) The CA PKI knowing that the domain name owner will alwas compress the certificate to zero bytes actually sends the domain name owner a pre-compressed certificate of zero bytes (saving the domain name owner the overhead of having to do this on every transaction).

8) All domain name transactions are authenticated using standard CA PKI digital processes and with valid compressed zero-byte certificates appended to every transaction.

for more discussion on this technique of valid compressed zero-byte certificates see:

http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2

==================

example/scenerio #3

examining the domain name infrastructure it appears that it has alwas been a certification authority for binding of information since its inception.

The primary differences

1) OCP ... it has alwas supported an online certificate protocol (as opposed to an online certificate status protocol) with the ability to return the certificate of bound information in real time (some modulo regarding the trust level of these "certificates"). these weren't public key infrastrucutre or public key certificates and they were presumed to have extremely short lifetimes. The protocol did support requesting a variety of bound information, domain name to ip-address as well as domain name to various other kinds of bound information

2) SLDDAP ... the super light weight distributed directory protocol. In support of OCP the domain name infrastructure also supported the super light weight distributed directory protocol where the bound information for the DNS "certificates" were distributed in for efficient and scalable real-time access.

In conjunction with scenerio #2 where the domain name infrastructure adds a CA PKI (with the registration of public keys and relying-party-only domain name owner certificates) to use the OCP protocol options to request a real-time certificate containing the bound information (from the domain name infrastructure ) containing a) domain name, b) ip-address, c) domain name owner's public key.

Given that this form of domain name infrastructure certificate contains public key in the bound information then one could consider it a public key infrastructure certificate (modulo peoples' opinion regarding the current integrity and trust in the domain name infrastructures' bound information and whether or not this is a pki or a PKI).

So lets return to the scenerio #1 trivial case (the situation that covers 99.9999999999999% of the current clients checking some information in a server certificate).

For the SSL protocol case which would seem to have the higher integrity:

1) current SSL domain name certificate manufactured at some point way in the past (and possibly containing stale information) which is dependant on the domain name infrastructure for the validity of the information.

2) a DNS OCP real-time public key infrastructure from the domain name infrastructure and is dependant on the domain name infrastructure for the validity of the information.

Both certificates have their fundamental integrity and trust built on the same domain name infrastructure:

a) one certificate is manufactured way in the past and has increasing probability of containing stale information.

b) the other certificate is manufactured in real-time in response to an immediate request for bound information.

"David P. Kemp" on 09/01/2000 09:53:20 AM
To:   ietf-pkix@xxxxxxxx
Subject:  Re: Client-side revocation checking capability
What is the threat that the PKI is addressing? My assumption is that in 99.99999999% of the cases the company hosting the web server is interested in preventing the following:
    user sees "www.companyA.com" on an advertisement and types it in, or clicks a link.
    DNS has been hijacked, the user connects to a bogus server, and the user gives up his personal info to the bad guy. Or the user sees a parody of www.companyA.com, or worse.


A server certificate issued by a CA to the company binds a company name (real world and/or DNS) to the company's private key. If DNS has been hijacked, the bad guy still can't impersonate the company web site. I'd say that 99.999999% of the relying party checking involves seeing the company's legitimate content; the DNS name is largely irrelevant for the user's purposes. The user could type an IP address, or any one of a number of DNS names, and as long as he gets to the company's information he couldn't care less how he got it.

In fact, including DNSnames in relying party (browser) checking causes unnecessary problems with virtual hosting. "www.CompanyA.com" should be a DNS *Name*, something the user types when he wants to see CompanyA's information. It shouldn't be any problem if CompanyA's information is actually being served from
https://www.hosting-service.com/account51/; the only thing that matters is that the user can be referred from what he types to where the information resides, and that the legitimate information provider has CompanyA's private key.
DNS security should be about binding DNS names to IP addresses, and should have nothing to do with EE keys.
PKI security should be about binding names (DNS, rfc822, or a real world brand name - "Ford Motor Company") to keys. The CA's responsibility is to ensure that the brand owner and the key are properly matched - this is far beyond the scope of a DNS administrator's duties.
application security should be about protecting whatever is meaningful about the user with the user's private key. In the case of web servers, what is meaningful is the company's content, not a DNSname.


If you try to take shortcuts (by combining DNS and PKI, for example), you prevent useful things from happening. DNS security supports infrastructure availability; PKI supports application security. Unnecessarily sacrificing web server functionality for security just gives security a bad name. And increasing the DNS administrator's workload hinders the adoption of simple yet valuable name-to-IP security.

Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/18/2000 01:42 PM
To: paul.kierstead@xxxxxxxx
cc: cryptography@xxxxxxxx, cypherpunks@xxxxxxxx
Subject: RE: Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
there are issues about authentication ... like conceptual frame-works of something you have, something you know, and something you are. it is possible to put together digital signature authentication technology/frame-works involving digital signature that are dependent on one or more pieces of 3-factor authentication.

legal "signatures" as indication of intent have involved issues like counterfeit and understanding (and various regulations about font-sizes, wording, different expectations about prudent person, etc).

a digital signature, once executed is a lot harder to counterfeit (compared to various written signatures) ... however there is much less direct correlation between intention and the act of executing a digital signature. digital signature in conjunction with various process that can proove that every digital signature executed was directly dependant on various combinations of 3-factor authentication (for each and every digital signature executed) attempts for a tighter correlation and demonstrate some degree of actual binding (between intention and signature execution).

however, they also introduce new technology challenges ... there is now a significantly wider gap between the presentation of the information that a person may be agreeing to ... and the actual representation that is involved in executing digital signatures.

paper documents also have had the advantage that the presentation of the information and the signature application is nearly identical technology .... much closer binding between the representation of what is being agreed to and the method of indicating that agreement.

There are not a whole lot of cases where as the person is using a pen to sign a specific piece of paper ... that the pen can wonder off and sign a totally different piece of paper (like radar getting week-end passes signed in the MASH show).

So the understanding issue pretty much stays the same in both environments (digital signature and paper signature) ... digital signatures (in conjunction with the appropriate authentication framework) can reduce the instances of counterfeit signatures being applied to documents ... but also opens up the instances where what a person is presented isn't necessarily what the person is signing.

So one issue might be ... all other factors being equal ... is the magnitude of any counterfeit reduction significantly greater than the increase in the "what you see is what you sign" problem and the "did the person actually intend/confirm that particular signature" problem.

"Paul Kierstead" on 11/17/2000 06:09:02 AM
The Word example actually has other worrying problems not mentioned. A Word document contains a lot of hidden information, including other versions. It would be quite easy to sign a Word document that, when you viewed it, looks significantly different then it could be displayed without violating the signature. This is due to numerous problems, the most basic of which is that we often don't sign what we view but instead some binary that we _believe_ represents what we viewed but often does not. This is not just theoretical nor esoteric, but quite easy as the Word example shows.

In effect we have absolutely no idea what we are signing most of the time even without comprimise of keys, programs and all that good stuff.

At 5:58 PM -0600 on 11/15/00, Bruce Schneier wrote:
>
>     Why Digital Signatures Are Not Signatures
>

Public Key Infrastructure: An Artifact...

Refed: **, - **, - **
From: Lynn Wheeler
Date: 11/18/2000 08:02 PM
To: Bram Cohen <bram@xxxxxxxx>
cc: Ben Laurie <ben@xxxxxxxx>, obfuscation@xxxxxxxx, rah@xxxxxxxx, cryptography@xxxxxxxx, cypherpunks@xxxxxxxx, dbs@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
note also that current SSL infrastructure is vulnerable to things like domain name hijacking; aka, at least part of SSL protocol is to make sure that you really are talking to the host that you think you are talking to ... i.e. the SSL certificate contains host/domain name (all this, in theory because of weaknesses in the domain name infrastructure) ... and when SSL goes to check something in the certificate ... it is checking the hostname/domainname against the hostname/domain name that the browser is using.

However, SSL-certificate issuing CAs have to rely on the domain name authoritative infrastructure with regard to issuing SSL-certificates & domain name ownership issues ... this is the same authoratative infrastructure that supposedly can't be relied on and justifies having a the whole SSL-certificate infrastructure to begin with.

In any case, the domain name infrastructure has been looking at ways to beef up the integrity of its operation ... like having public keys registered as part of domain name registration. Now, if domain name infrastructure is going to use public key registration as part of beefing up its integrity ... that would medicate much of the justification for the SSL-certicate infrastructure.

Furthermore, if a higher integrity domain name infrastructure included public keys in the domain name record ... clients could request a real-time, trusted copy of the public key as a adjunct to host-name lookup. This would further eliminate the requirement for any certificate involvement in the majority of the existing SSL transaction operation (i.e. client gets the public key at the same time hostname resolution is done ... the client can trust a real-time host/domain name because of the improvement in the domain name infrastructure integrity ... and at the same time it can trust a real-time publickey for the same host/domain).

Bram Cohen on 11/18/2000 11:15:38 AM
On Sat, 18 Nov 2000, Ben Laurie wrote:
> Bram Cohen wrote:
> >
> > And if you build a protocol which is a pain to use, noone will use it.
>
> What, like SSL, for example?
SSL is not a pain to use, and it isn't effective against man in the middle attacks, since an attacker could simply make the end user connection be done via unencrypted http and most end users wouldn't notice.

It is, however, quite effective against passive attacks, which is all that's really important.

-Bram Cohen

Public Key Infrastructure: An Artifact...

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/18/2000 09:34 PM
From: Lynn Wheeler
To: Ben Laurie <ben@xxxxxxxx>
cc: Bram Cohen <bram@xxxxxxxx>, obfuscation@xxxxxxxx, rah@xxxxxxxx, cryptography@xxxxxxxx, cypherpunks@xxxxxxxx, dbs@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Public Key Infrastructure: An Artifact...
the current SSL domain name infrastructure supposedly exists because of issues with trusting the domain name infrastructure ... except the SSL domain name certificate issuer has to trust the same (untrusted) domain name infrastructure when issuing a certificate (i.e. the SSL domain name certificate is no better than the authentication authority that the certificate authority has to rely on as the final arbitrator of domain name ownership).

one of the integrity issues with the domain name infrastructure ... is that domain names have been hijacked ... once hijacked ... you can go to certificate authority and get a certificate with that domain name (and the certificate authority will check with the domain name system and confirm that the requester owns the domain name).

for more ... see merchant comfort certificate thread at

http://www.garlic.com/~lynn/aepay4.htm

specific news clipping on hijacking

http://www.garlic.com/~lynn/aepay4.htm#dnsinteg1

so, the scenario goes that to fix various exposure & integrity risks to SSL domain name certificate infrastructure, the domain name infrastructure that the certification authority relies on needs to have its integrity fixed. the proposal for fixing the domain name infrastructure (on which the SSL domain name certificate issuing authority relies on as the authoritative reference for domain names) is to register public keys at the same time domain names are registered.

now the interesting catch-22 is that SSL domain name certificates were in part justified because of weaknesses in the integrity of the domain name infrastructure ... however in order to issue those same SSL domain name certificates, the SSL domain name issuing authority (certificate authority) has to rely on the same domain name infrastructure (that everybody is being told that you can't really trust because of integrity problems ... aka everybody isn't to rely on domain name infrastructure ... because it can't be trusted ... so buy a SSL domain name certificate .... however the SSL domain name certificate issuing certification authority is allowed to rely on the same domain name infrastructure for its authoritative information.

The SSL domain name certificate issuing certification authority just isn't telling everybody that it has to reference the domain name infrastructure in order to validate a request for an SSL domain name certificate.

I would call that ironic???

Now for even more ironic. In order to fix various integrity exposures in the SSL domain name certificate ... integrity exposures in the domain name infrastructure have to be fixed (i.e. integrity is nominally no stronger than the weakest link). However, fixing integrity exposures in the domain name infrastructure (in order to fix various integrity exposures in SSL domain name certificates) ... can make those certificates redundant, superfluous, and unnecessary.

Now the issue isn't to use either SSL domain name certificates or domain name infrastructure. Since SSL domain name certificates issuance relies on the domain name infrastructure for its authoritative information ... then the infrastructures that the SSL domain name certificates issuance certification authority relies on has to have its integrity fixed.

Now, I considered this somewhat ironic ... that in order to fix a integrity dependency that SSL domain name certificate issuance has ... the fix also eliminates much of the original justification for SSL domain name certificates (i.e. weaknesses in the domain name infrastructure) as well as making SSL domain name certificates redundant and superfluous.

SSL domain name certificates provide a binding between public key and domain name. However, if public keys were registered with domain names in the domain name infrastructure ... the purpose of which was to fix various integrity problems in the domain name infrastructure and allow the domain name infrastructure to be trusted by the SSL domain name certificate issuing certification authority ... then the integrity of the domain name infrastructure can be fixed for everybody ... eliminating the purpose of the SSL domain name certificate (aka integrity problems with the domain name infrastructure). Furthermore, if public keys were registered with domain names, then the domain name infrastructure could serve up real-time bindings of public keys and domain names (as part of the domain name lookup process).

If a SSL protocol ... when it asked the domain name system to resolve a domain name ... could set a flag and asked that both the resolved domain name and the registered public key be returned ... the efficiency of the SSL protocol would be improved.

All in all

1) fixing integrity of domain name infrastructure (so you can trust SSL certificates) eliminates much of the requirement for SSL certificate (i.e. needed because of integrity problems in the domain name infrastructure

2) fixing integrity of domain name infrastructure with the registration of public keys and making that information public as part of standard domain name infrastructure provides a trusted binding between domain name and public key ... making the SSL domain name certificate redundant and superfluous.

Now as to the other kind of certificate. My wife and I were hired by a financial services company in 1994 to work with a small client/server startup on the peninsula that wanted their server to be able to interface to the financial transaction infrastructure. One of the things that I eventually specified as part of that infrastructure was a consumer oriented certificate (along the lines of BBB, consumer reports, etc). However, the whole thing was in its infancy and they were having enuf other problems creating infrastructures ... so it has yet to happen. Two people my wife and I worked with at the startup are referenced in the following:

http://www.garlic.com/~lynn/aadsmore.htm#dctriv

random other refs:
http://www.garlic.com/~lynn/aadsmore.htm#client3
http://www.garlic.com/~lynn/aadsmore.htm#client4
http://www.garlic.com/~lynn/96.html#32
http://www.garlic.com/~lynn/2000b.html#18
http://www.garlic.com/~lynn/95.html#13

AADS Postings and Posting Index, next, previous - home