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 scale-up issue proportional to the
size of the population ... and somewhat independent to the number of
transactions &/or connections. Online scale-up (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
https://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:
https://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
https://www.garlic.com/~lynn/
and example of the mapping to 8583 see
https://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
https://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:
https://www.garlic.com/~lynn/96.html#15
https://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
https://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
https://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 https://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/
https://www.garlic.com/~lynn/
and specific ...
https://www.garlic.com/~lynn/99.html#224
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo1
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo2
https://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
https://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:
https://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:
https://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
&
https://www.garlic.com/~lynn/ansiepay.htm#theory
https://www.garlic.com/~lynn/ansiepay.htm#privacy
https://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:
https://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
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo1
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo2
https://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
explanation 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:
https://www.garlic.com/~lynn/aepay4.htm
https://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:
https://www.garlic.com/~lynn/99.html#71
https://www.garlic.com/~lynn/99.html#128
https://www.garlic.com/~lynn/ansiepay.htm#aadsnew2
https://www.garlic.com/~lynn/aepay2.htm#position
mapping of the draft x9.59 financial standard to existing online networks:
https://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
https://www.garlic.com/~lynn/aepay4.htm#rfc2807b
https://www.garlic.com/~lynn/aepay4.htm#rfc2807c
general rfc index ... can pick out radius from the terms index
https://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:
https://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
https://www.garlic.com/~lynn/aepay4.htm
specific news clipping on hijacking
https://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:
https://www.garlic.com/~lynn/aadsmore.htm#dctriv
random other refs:
https://www.garlic.com/~lynn/aadsmore.htm#client3
https://www.garlic.com/~lynn/aadsmore.htm#client4
https://www.garlic.com/~lynn/96.html#32
https://www.garlic.com/~lynn/2000b.html#18
https://www.garlic.com/~lynn/95.html#13
AADS Postings and Posting Index,
next, previous
- home