Defense Dept. Criticized on Internal Credit Card Fraud From
AmericanBanker
Federal investigators testified before a House Governmental Affairs
subcommittee Wednesday that the Defense Department's efforts to curb
credit card fraud by employees have been ineffective.
Commanding officers from the Navy Public Works Center and the Space
and Naval Warfare Systems Center, which were investigated by the
General Accounting Office from November to February, also appeared at
the hearing to pledge further reform. But the vows were met by stern
words from skeptical lawmakers.
"We are now going to be considering a budget that requests an
unprecedented increase in the defense budget, and I think it is
appropriate to scrutinize every dollar, every million dollars, every
billion dollars," said Janice D. Schakowsky, D-Ill.
Definese Dept Criticised on Internal Credit Card Fraud
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/17/2002 01:23 PM
To: epay@xxxxxxxx
Subject: RE: Definese Dept Criticised on Internal Credit Card Fraud
(possible resend?? ... I'm getting solid database corrupt, unable to
allocate space error message when attempting to transfer this to the
corporate server)
oh well, little finger fumble. i'm well known (infamous) for it (even 20 years ago).
there was a researcher in the early '80s that sat in the back of my
office, went to me with meetings, got copies of all my email and logs
of instant messages for a 9 month period. A detailed analysis turned
into PhD sort of in CMC (computer mediated communication) ... joint
between the language dept & computer AI dept at stanford (analysis of
face-to-face, telephone, meeting, one-on-one, email, mailing lists,
newsgroups, instant messages, etc ... compared & contrasted). Part of
it including early computer conferencing with early mailing list
technolgies (various precursors to current listserv &
majordomo). There was also some subsequent books and papers published
involving some of the same material (aka Knowledge Machines, Language
and Information in a Technoligical Society).
random listserv/majordomo:
https://www.garlic.com/~lynn/99.html#225 BBSs vs. The Internet
https://www.garlic.com/~lynn/aepay10.htm#7 UNCITRAL Electronic Contracting Project
https://www.garlic.com/~lynn/2000.html#38 Vanishing Posts...
https://www.garlic.com/~lynn/2000g.html#39 Could CDR-coding be on the way back?
https://www.garlic.com/~lynn/2001c.html#19 What is "IBM-MAIN"
https://www.garlic.com/~lynn/2002d.html#33 LISTSERV(r) on mainframes
https://www.garlic.com/~lynn/2002e.html#6 LISTSERV(r) on mainframes
misc. refs to stanford phd:
https://www.garlic.com/~lynn/aepay2.htm#position AADS NWI and XML encoded X9.59 NWI
https://www.garlic.com/~lynn/99.html#205 Life-Advancing Work of Timothy Berners-Lee
https://www.garlic.com/~lynn/2001j.html#29 Title Inflation
https://www.garlic.com/~lynn/2001k.html#64 Programming in School (was: Re: Common uses...)
https://www.garlic.com/~lynn/2002b.html#51 "Have to make your bones" mentality
https://www.garlic.com/~lynn/2002c.html#27 OS Workloads : Interactive etc
slightly related:
https://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
https://www.garlic.com/~lynn/2001g.html#6 New IBM history book out
https://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
https://www.garlic.com/~lynn/2001j.html#31 Title Inflation
https://www.garlic.com/~lynn/2002e.html#10 Deleting files and emails at Arthur Andersen and Enron
tlewis@xxxxxxxx on 3/15/2002 7.04 pm wrote:
Definise Dept.? Is that the government deparment responsible for removing
finesse from government publications? If so, they do their job extremely
well.
Tony
-----Original Message-----
From: Lynn Wheeler [mailto:lynn.wheeler@xxxxxxxx]
Sent: Thursday, March 14, 2002 9:09 PM
To: Lewis, Tony
Subject: Definese Dept Criticised on Internal Credit Card Fraud
[dgc.chat] XML/X - part I
From: Lynn Wheeler
Date: 04/07/2002 07:41 PM
To: epay@xxxxxxxx
Subject: Re: [dgc.chat] XML/X - part I
or get really wierd and start talking about TPC ACID properties.
Atomicity
Either the transaction completes, or nothing happens at all. When a
transaction fails in the middle of operation, the operations that
have taken place should be rolled back.
Consistency
A transaction must begin in a consistent state and leave the system in
a consistent state.
Isolation
No other participants are allowed to access the intermediate
results. All intermediate operations are performed in
isolation. Outside participants are only allowed access once a
consistent state has been reached.
Durability
Once a server has committed to a transaction, it completes the
transaction even if it suffers a system failure.
ref: The Benchmark Handbook for Database and Transaction Processing
Systems, Jim Gray, ed, Morgan Kaufmann.
random refs:
https://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/2000.html#18 Computer of the century
https://www.garlic.com/~lynn/2000b.html#29 20th March 2000
https://www.garlic.com/~lynn/2001.html#6 Disk drive behavior
https://www.garlic.com/~lynn/2001g.html#7 New IBM history book out
https://www.garlic.com/~lynn/2001k.html#15 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2002d.html#5 IBM Mainframe at home
t.c.jones@xxxxxxxx on 3/27/2002 6:54 pm wrote:
Idempotency - whoa!
the same idea is included in ANSI X9.59 - it is call a
LUID there. See the following snippet of XML that i
proposed to implement it. ..tom
<?xml version="1.0" encoding="UTF-8" ?>
<!-- ANSI X9.59 secure payment object definitions -->
<!DOCTYPE X9Adocument (View Source for full doctype...)>
<XAdocument>
<PAYREQ version="1">
<Merchant name="Frank's Fraudulent Flea Market">1,5879156</Merchant>
<Transaction payCode="x" LUID="113" startDate=""
endDate="20010628" merchantTrac="123-4567890">79541USD</Transaction>
<Consumer>2,6652827</Consumer>
</PAYREQ>
<Result Action="Accept">200 OK</Result>
<TOKSIG>2938d77e8a5f827</TOKSIG>
<APPSIG>098d7a855f822b1</APPSIG>
</XAdocument>
> Date: Mon, 25 Mar 2002 23:03:13 -0500 (EST)
> From: Ian Grigg <iang@xxxxxxxx>
> To: xml-api@xxxxxxxx
> Subject: [dgc.chat] XML/X - part I
> Cc: dbs@xxxxxxxx, dgcchat@xxxxxxxx
> Sender: owner-dgcchat@xxxxxxxx
> Reply-To: dgcchat@xxxxxxxx
>
> It is with some satisfaction that we announce the first
> public demonstration of a new project that we've been
> working on for the last six months.
>
> This demonstration is taking place at Java 1 this week,
> by Erwin Van der Koogh, a programmer with Sun's XML group
> in Dublin. He's also a WebFunds programmer, having been
> primarily responsible for the current generation.
>
> You can check out a scratch home page for the project at:
>
> http://www.webfunds.org/guide/xml/
>
> We were looking some time ago at the difficulty faced
> by the various merchants in implementing access to the
> current money providers. As no merchant could really
> predict where the good money was, so to speak, it was
> pretty obvious that being able to implement a range of
> gold-based units was much less risky.
>
> But it was also rather impossible. The transfer methods
> for the systems ranged from pretending to be a browser,
> to accessing partially complete protocols to .. nothing.
> None of the systems in place seem to appeal as none of
> them have actually been thought out from the point of
> view of what we know about protocols and networks.
>
> It behoved us to come up with our own spend system. We
> were in the throes of developing our own web-based system,
> and we wanted that bit right. After all, a lot of demand
> comes from the support of the merchant class (a group we
> christened as Matildas, but that's a story for another
> day).
>
> Others, such as Intertrader, were still smarting at the
> cost of having developed access for different systems,
> and not having been able to efficiently deploy it because
> of the system bugs imposed on them. And, yet others
> simply didn't know where to start.
>
> It all begged for a standard. We sat down and drew one
> up. Now, because standards committees tend to be noisy,
> rumbunctious, and ultimately unproductive, unless they
> have a very solid mission to draw from, we decided not
> to make this a publicity thing in the beginning. That
> is, we decided to write it first, then open it up.
>
> All well and good, and of course, we chose to do our
> transfer interface in XML. We called it XML/X as a
> quick code name for the project, being transactions in
> XML. The results will be open source, the documentation
> will be readily available, and no fees will be levied on
> joining or using. Even though this project is about
> money, it makes more monetary sense to impose no barriers
> on its widespread adoption.
>
> A quick example might clarify what all this hyperbole is
> about. Imagine you have some accounts at a standard DGC
> such as e-gold, goldmoney, or one of those other systems
> such as PayPal. As a merchant, you want to initiate a
> transaction from your automated web system to pay out a
> customer. Or vice versa.
>
> So, you open up a connection to the money server and
> send down a stream of commands to cause it to happen.
> Here's how you would do it in today's XML/X:
>
> <TransferRequest>
> <Transfer>
> <ClientID> P9348235 </ClientID>
> <Payee> E3491 </Payee>
> <Payer> 34201-543 </Payer>
> <Amount> 45.23 </Amount>
> <Currency> Platinum </Currency>
> <Memo> Slicker than Slick </Memo>
> </Transfer>
>
> <Auth>
> <Username> iang </Username>
> <Password> Rock On </Password>
> </Auth>
>
> </TransferRequest>
>
> (Take that as an alpha - it's still evolving and is
> likely to change.) Consider this one feature as an
> example: In our XML/X, you can do a one-shot transfer
> and get a reliable result. It's reliable because you
> can resend it (see the <ClientID>?), and get the same
> result - one and only one transaction, as long as the
> server saw the instruction and acted at least once.
>
> That's pretty useful. In fact, it's so useful it
> is blessed with the otherwise indecipherable term of
> _idempotency_ (which means, it happens zero times or
> once, no matter how many times you send it). There are
> lots of other useful features, but they lack general
> interest unless one has social disabilities and wears
> a propellor.
>
> How useful would all that be to a cambist?
>
> Such near-latin would be even more useful if all systems
> offered the same interface. By designing in elements
> of protocols, it makes sense to adopt this one rather
> than roll your own. As an aside, XML/X incorporates
> elements from SOX, the most reliable protocol for money
> I've ever seen, although I admit to being a tad biased.
>
> But the best is yet to come...
>
> TO BE CONTINUED...
Electronic Commerce Modeling Language (ECML):Version 2 Specification
From: Lynn Wheeler
Date: 05/01/2002 09:24 AM
To: epay@xxxxxxxx
Subject: Electronic Commerce Modeling Language (ECML):Version 2 Specification
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Open Trading
Protocol Working Group of the IETF.
Title : Electronic Commerce Modeling Language (ECML):Version 2
Specification
Author(s) : J. Parsons, D. Eastlake
Filename : draft-ietf-trade-ecml2-spec-03.txt
Pages : 22
Date : 30-Apr-02
Electronic commerce frequently requires a substantial exchange of
information in order to complete a purchase or other transaction,
especially the first time the parties communicate. A standard set of
hierarchicly organized payment related information fields in an XML
syntax are defined as the second version of an Electronic Commerce
Modeling Language (ECML) so that this task can be more easily
automated, for example by wallet software
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-trade-ecml2-spec-03.txt
Using Microsoft Word to create Internet Drafts and RFC's
From: Lynn Wheeler
Date: 05/01/2002 09:25 AM
To: epay@xxxxxxxx
Subject: Using Microsoft Word to create Internet Drafts and RFC's
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Using Microsoft Word to create Internet Drafts and
RFC's
Author(s) : M. Gahrns, T. Hain
Filename : draft-hain-msword-template-08.txt
Pages : 18
Date : 30-Apr-02
This document will describe the steps to configure the Microsoft Word
application to produce documents in Internet Draft and RFC format.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hain-msword-template-08.txt
Economics of financial applications of the smart card
From: Lynn Wheeler
Date: 05/24/2002 08:25 AM
To: eapy@xxxxxxxx
Subject: Economics of financial applications of the smart card
Economics of financial applications of the smart card (added: 24-May-2002)
http://europa.eu.int/ISPO/fiwg/archives/steering/fasc.htm
The outlook for the financial applications of the smart card (FASC),
such as debit security, electronic purse or multi- functional payment
card, appears highly controversial and unsettled. On the one hand,
there are optimists who predict that FASC will become ubiquitous
within the next few years both in the physical and the virtual
worlds. On the other hand, there are sceptics who see FASC confined to
few niche market segments. The actual deployment of FASC follows a
disparate pattern, with strong geographical variations. FASC are
rolled out on a large-scale, in hundreds of million of units, in
Europe, while they remain in pilot stages of small-scale experiments
in the United States and Japan.
some certification & authentication landscape summary from recent threads
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/01/2002 12:48 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: some certification & authentication landscape summary from recent threads
real-word, real-time certification transactions
===============================================
One of the most familiar world-wide electronic certification
transactions is the point-of-sale payment card transaction. basically
a customer makes an assertion about paying the receipt ... and the
consumer/issuing financial institution either agrees to certify that
assertion or not. if the financial institution agrees to certify that
assertion ... it typically assumes some amount of financial liability
for each and every certification transaction that it performs. this is
somewhat different from the offline, certificate based model where the
certifying institution (CA or certification authority) may have no
idea how many and/or what kind of transactions that their
"certificate" is involved in (and as a result there is little way of
truely doing any kind of real time risk exposure assesement).
Some of these real-time electronic certification transactions include
a name & address certification option (i.e. in addition to the payment
assertion, there can be an optional name & address assertion)
typically referred to as AVS. Some number of web/internet based
businesses have discovered how to perform an ersatz electronic payment
transaction that includes AVS certification w/o any item appear on the
consumer's monthly statement (the consumer doesn't know that it
happened and/or doesn't see any charge associated with it).
This is significantly different than the offline certificate model ...
where a certified trusted electronic document is created at some time
in the past regarding some stale, static information which is then used
in potentially arbritrary & unknown number of operations.
These real-time certification operations have the interesting
characteristic that the fees charged are between the institution
performing each certification and the relying party that is going to
be relying on the certification. This differs from the typical
certificate-based model where the consumer is being charged for their
certificate ... not the relying-party. Given the realtime
certification fee model ... one might expect to see a situation in the
consumer paid certificate model ... where the relying party
re-imburses the consumer some value for each time the certificate is
checked.
X9.59
=====
x9.59 is designed to add digital signature authentication to all
payment related electronic real-time assertions. The objective is
reducing the fraud and risk exposure on a per transaction basis by
providing end-to-end integrity of the asserted transaction. In turn
this should lower the liability exposure to the certification
authorities (issuing institutions) that are performing the real-time
certification responses.
https://www.garlic.com/~lynn/subintegrity.html#fraud
https://www.garlic.com/~lynn/x959.html#x959
FSTC FAST
==========
financial authenticated secure transaction .... basically is looking
at extending the prevelent real-word,real-time, online, electronic
certification transaction to things in addition to paymemt, name and
address. One of the assertion items mentioned was age ... that a
signed assertion is made as to being younger or older than some value
... and the financial institution would certify the assertion.
It is possible to take the X9.59 specification and its mapping to
various existing real-time payment transactions and perform a similar
mapping to real-time FAST certification transactions.
Real-world internet authentication
==================================
Probably the highest incidence/frequency of real-world internet
authentication events today involves RADIUS typically with
userid/password (majority of ISP, corporate networks, boundary
routers, etc).
As part of the work on supporting FIPS186-2, ecdsa digital signature
authentication (see mappings documented for x9.59) ... a version of
RADIUS with FIPS186-2 ecdsa is being made available. RADIUS supports
multiple authentication mechanisms and different mechanisms can be
specified on a user by user (or account by account) basis. The
FIPS186-2 case effectively registers a public key for the account (in
lieu of a password) and performs FIPS186-2 authentication ... in place
of password.
https://www.garlic.com/~lynn/subpubkey.html#radius
also
https://www.garlic.com/~lynn/rfcietff.htm
and select "TERM->RFC#", then select RADIUS in the acronym "fastpath" at
the front of the entry. This will give pointers to all the RADIUS related
internet standard RFCs
Real-world internet authentication
==================================
For campus, departmental, and server type operations, one of the
emerging security mechanisms is Kerberos. This was developed at
Project Athena 15 or so years ago. This appears in windows 2000,
various unixes and various mainframes. Kerberos is also an internet
RFC standard. Use similar procedure in the "TERM->RFC#" but scroll
down to the Kerberos entry to get a list of all Kerberos related RFCs.
There is a internet standard draft in progress (not yet made it to RFC
status) that specifies the use of public key authentication in
conjunction with Kerberos. This draft is agnositc whether the public
key is supplied with a certificate or is registered in place of the
password in the Kerberos userid/priveleges database.
Internet public key events
==========================
Possibly 99.999 percent of the public key events occuring on the
world-wide internet is done in conjunction with SSL and "manufactured
certificates".
The nominal purpose for these "manufactur certificates" is so that the
SSL transaction can check the domain name typed-in for the URL against
the domain name in the certificate. The issue is questions about
domain name infrastructure integrity and its ability to provide
trusted responses to requests of mapping a domain name to an
IP-address.
Note however, that the authoritative agency that all CAs have to
check with as to the validity of a asserted domain name ... prior to
certifying and manufacturing the certificate ... is the domain name
infrastructure. As a result CAs are dependent on the very same domain
name infrastructure that everybody else is. There are proposals to
improve the operational integrity of the domain name infrastructure
.... in part so that CAs can better trust the information that they
are certifying. One item is for people registering their domain name
and ip address ... to also register their public key at the same time.
Now
1) improving the integrity of the domain name infrastructure for CAs
... also improves it for everybody ... and lowers the need for SSL
domain name certificates
2) domain name infrastructure has a generalized mechanism for
real-time distribution of information ... not restricted to ip-address
response. If the domain name infrastructure had registered public keys
... they could distribute such public keys in the same response when
they distributed ip-addresses ... further reducing the need for SSL
domain name certificates. Note this also could significantly simplify
and reduce the SSL protocol startup chatter (as well as totally
eliminating requirement for certificates)
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
=========================================================
... trivia question ... from earlier posting:
https://www.garlic.com/~lynn/aadsmore.htm#dctriv Digital Commerce Trivia Question
some certification & authentication landscape summary from recent threads
From: Lynn Wheeler
Date: 06/02/2002 07:42 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: some certification & authentication landscape summary from recent threads
and of course small brain check:
that should have been
https://www.garlic.com/~lynn/rfcietff.htm
in the rfc specific summaries ... clicking on the ".txt=" field retrieves
the actual RFC.
the procedures uses to generate the index also does knowledge based type
consistency checking on the transitions ... a subset of the consistency
result used to appear in section 6.10 in earlier STD1 (i.e. standard #1, a
specific RFC periodically re-issued as overall internet standard
reference).
examples:
remote authentication dial in user service (RADIUS )
see also authentication , network access server , network services
3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139
2138 2059 2058
specific RFC summary
2865 DS
Remote Authentication Dial In User Service (RADIUS), Rigney C., Rubens A.,
Simpson W., Willens S., 2000/07/05 (76pp) (.txt=146456) (Updated by 2868
) (Obsoletes 2138) (RADIUS)
some kerberos
Kerberized Internet Negotiation of Keys
see also kerberos
3129
kerberos
see also authentication , security
3244 3129 2942 2712 2623 1964 1510 1411
specific rfc summary
1510 PS
The Kerberos Network Authentication Service (V5), Kohl J., Neuman C.,
1993/09/10 (112pp) (.txt=275395) (KERBEROS)
lynn.wheeler@xxxxxxxx on 6/1/2002 12:48 pm wrote:
also
https://www.garlic.com/~lynn/rfcietff.htm
and select "TERM->RFC#", then select RADIUS in the acronym "fastpath" at
the front of the entry. This will give pointers to all the RADIUS related
internet standard RFCs
pk-init draft (not yet a RFC)
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/02/2002 08:19 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: pk-init draft (not yet a RFC)
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-cat-kerberos-pk-init-15.txt
2. Introduction
The popularity of public key cryptography has produced a desire for its
support in Kerberos [2]. The advantages provided by public key
cryptography include simplified key management (from the Kerberos
perspective) and the ability to leverage existing and developing public key
certification infrastructures.
Public key cryptography can be integrated into Kerberos in a number of
ways. One is to associate a key pair with each realm, which can then be
used to facilitate cross-realm authentication; this is the topic of another
draft proposal. Another way is to allow users with public key certificates
to use them in initial authentication. This is the concern of the current
document.
PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in combination with
DSA keys as the primary, required mechanism. Note that PKINIT supports the
use of separate signature and encryption keys.
PKINIT enables access to Kerberos-secured services based on initial
authentication utilizing public key cryptography. PKINIT utilizes standard
public key signature and encryption data formats within the standard
Kerberos messages. The basic mechanism is as follows: The user sends an
AS-REQ message to the KDC as before, except that if that user is to use
public key cryptography in the initial authentication step, his certificate
and a signature accompany the initial request in the preauthentication
fields. Upon receipt of this request, the KDC verifies the certificate and
issues a ticket granting ticket (TGT) as before, except that the encPart
from the AS-REP message carrying the TGT is now encrypted utilizing either
a Diffie-Hellman derived key or the user's public key. This message is
authenticated utilizing the public key signature of the KDC.
Note that PKINIT does not require the use of certificates. A KDC may store
the public key of a principal as part of that principal's record. In this
scenario, the KDC is the trusted party that vouches for the principal (as
in a standard, non-cross realm, Kerberos environment). Thus, for any
principal, the KDC may maintain a symmetric key, a public key, or both.
The PKINIT specification may also be used as a building block for other
specifications. PKINIT may be utilized to establish inter-realm keys for
the purposes of issuing cross-realm service tickets. It may also be used
to issue anonymous Kerberos tickets using the Diffie-Hellman option.
Efforts are under way to draft specifications for these two application
protocols.
Additionally, the PKINIT specification may be used for direct peer to peer
authentication without contacting a central KDC. This application of PKINIT
is based on concepts introduced in [6, 7]. For direct client-to-server
authentication, the client uses PKINIT to authenticate to the end server
(instead of a central KDC), which then issues a ticket for itself. This
approach has an advantage over TLS [5] in that the server does not need to
save state (cache session keys). Furthermore, an additional benefit is
that Kerberos tickets can facilitate delegation (see [6]).
some certification & authentication landscape summary from recent threads
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/03/2002 07:08 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: some certification & authentication landscape summary from recent threads
no discussion about SSL-client-auth work.
there is discussion about SS domain name server certificates and that
it supposedly addresses integrity issues with domain name
infrastructure .... but because CA authentication of of SSL server
certificate is also dependent on same infrastructure ... that CAs have
proposals to fix that domain name infrastructure. however the fix
then reduces original requirement for the certificates (fixing
integrity issues with domain name infrastructure). "fix" would also
enable domain name infrastructure to do real-time non-stale,
non-static distribution of public keys. furthermore, domain name
infrastructure doing real time distribution of public keys in the same
operation as ip-address distribution can improve SSL startup
efficiency and reduce the startup SSL message chatter.
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
there has been discusscion that the dominant client authentication
process in the internet/web today around the world (by possibly order
of magnitude) is radius related typically with userid/passwords (all
ISPs, corporate internets, routers, etc) ... as per previous note.
Not mentioned in previous note but in several discussions at:
https://www.garlic.com/~lynn/subpubkey.html#radius
is that majority of web servers ship with stub code for doing client
authentication. frequently people then implement userid/passwords in
flat files for client authentication.
however, some straight-forward code that could be shipped with every
web server would be some additonal code that would make radius calls
for doing client authentication. This has a significant administrative
benefit because a large number of web-servers doing client
authentication are at ISP web-farms. Such an implementation would
significantly reduce the costs & overhead for infrastructure
administration of client authentication by providing a single
structure implementation (across all client-authentication
operations). It further has the advantage that the single
adminstrative operation for doing all client authentication supports a
variety of client authentication mechanisms on a per client/userid
level (i.e. select userid/password, chap, public key, etc).
Note that the dominant form of client authentication in the web today
... userid/passwords (whether radius or not) works with standard
browsers of today. code going out on sourceforce.net is plugins that
support radius FIPS186-2, ecdsa signature authentication. this means
that the identical same process for authenticating the ISP connection
is then also available/usable for every other client authentication
in the internet/web world (with support for graceful, account by
account upgrade/transition).
This has the advantage of not being limited to just small number of
web server client authentications (as in SSL-client auth) but all
internet/web client authentications.
anders.rundgren@xxxxxxxx on 6/3/2002 1:37 am wrote:
Question: Does SSL-client-auth work without certificates? Using
standard browsers of today.
some certification & authentication landscape summary from recent threads
Refed: **, - **, - **
From: Lynn Wheeler
Date: 06/03/2002 07:14 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: some certification & authentication landscape summary from recent threads
oh i forgot to ask ... you said that the swedish does a 50 cent(?)
charge per OCSP transactions ... when the merchant/relying party sends
in the OCSP request .... do they transmit the value of the transaction
being certified? typically in risk management .... the entity
accepting liability in connection with the transaction likes to have
as good a handle on their exposure as possible ... aka ... not only
the number of transactions but also the per transaction exposure.
Identity server infrastructure ... example
From: Lynn Wheeler
Date: 06/03/2002 07:17 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Identity server infrastructure ... example
example of Identity server infrastructure (both certificates and
RADIUS ... possible to enhance RADIUS with fips186-2 ecdsa digital
signature authentication).
http://wwws.sun.com/software/products/identity_srvr/ds_identity.html
LDAP userid/password
X.509v3 digital certificates
RADIUS
Public service provider
landscape & p-cards
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/05/2002 06:11 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: landscape & p-cards
I'm not sure about "my way".
I worked with this small client/server startup in menlo park that
wanted to do electronic payment transactions. Putting up this thing
that was the original payment gateway ... in insisted that this thing
they had invented called SSL do "mutual" authentication (this was back
before there was SSL3) ... and i believe was the original
implementation that had both client and server doing certificate based
authentication. both the ability to do payments on these servers and
the use of client-based certificates seems to have a fairly wide
world-wide deployment. is that what you are referring to as "my way".
the case for AADS came out of the observation that even tho there were
client certificates in the payment gateway case ... all the actual
business processing was being done based on accounts ... the
certificates were a momentary facade based on the fact that was the
way the SSL code worked ... not how the business process worked. In
effect, that once the SSL code had done its bit, its way ... there was
a business process implementation that did its thing with
accounts. misc. refs:
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
or is it this thing called the internet .... misc. refs:
https://www.garlic.com/~lynn/internet.htm#0
the internet is disruptive technology ... being "open" and getting to
be ubiquitous (compared to the earlier closed networks). the
transition from close to open has increased the requirement for
authentication technology. Passwords have been a weaker
authentication technology as well as becoming more cubmersome as
electronic world expands and requirement for (shared-secret) passwords
to be unique in every domain. the issue with certificates is that they
really have a design point for the offline environment. the question
then is whether the future is going to be online paradigm or offline
paradigm. certificates really are a stale, static, (read-only), trusted
copy of some information sitting around in some account record. the
purpose of the certificate is to provide a copy of that stale
information when it isn't practical to access the real information.
now as to P-cards. the question is what is the primary business driver
for p-cards ... 1) outsourcing the business or 2) lack of in-house
connectivity. If the primary business driver for p-cards is lack of
in-house connectivity ... then there is some reasonable expectation
that as business connectivity increases, that purchase operations
return more in-house. if a primary business driver for p-cards has
been outsourcing to more experienced and scalable operations ... then
it is likely that p-cards become more prevalent.
a slightly related subject is that in the US, a majority of transit
funding comes from the federal government. The federal government have
been telling transit authorities that they need to be getting out of
the money collection business and turn it over to organizations that
specialize in such activity ... and concentrate just on what they are
funded for ... moving people. Presumably the reasoning 1) is that
organizaitons that specialize in moving money can do it more
efficiently than various transit authorities and 2) it shouldn't be
necessary for the federal gov. to be subsidizing development and
enhancement of transit-specific money collection and management
systems (when there are financial institutions that specialize in such
activity).
in the p-card case (& in transit) there is big difference between
real-time auth and the offline stuff that might be done with
credentials (aka ... 7-8 years ago ... it was pointed out that
credentails were analogous to the signing limit checks ... but then it
was observed that one of the reasons for migration to p-cards was
there was still fraud with signing limit checks ... offline model
didn't support real-time and/or transaction aggregation). while the
internet is inexpensive, reduces the cost of doing business and is
heading towards providing online ubiquitous connectivity ... one of
the reasons that it is inexpensive is just exactly that ... it is
inexpensive (aka there are things like SLAs lacking).
there was an incident a couple years ago where processing center had
divergent routing and redundancy ... with multiple central exchanges
feeding into the facility from different physical directions and
different physical wires. The central exchanges are suppose to
automatically reroute if there is a problem from any one
direction. this rerouting is suppose to be under a minute. this
particular case, the rerouting was delayed 17 minutes real time. this
caused ceo level discussion with the phone entity. imagine large
number of facilities not able to execute transactions (transit or
retail) during peak rush hour.
note that the p-card question implies expectation of online,
ubiquitous connectivity ... and is with regard to an online p-card
question is with respect to one online implementation (slightly more
expensive ... until you take into consideration availability and
scaleability) and another online implementation.
applying a similar expectation of online, ubiquitous connectivity
... is what raises the issue regarding certificates & certificate
based PKI which were invented specifically for addressing an
electronic but offline paradigm ... aka there wasn't going to be any
facitlity for directly connecting to the certification authority
and/or the authoritative agency for the information being certified
(aka in the SSL domain name certificates, while there is a
"certification authority" it is typically certifying information that
it has checked on with the authoritative agency as to the validity of
the information). If the authoritative agency with regard to the
information being validated was online line with ubiquitous
connectivity ... then certificates become redundant and superfluous
... as well as any certification authority (separate from the
authoritative agency).
anders.rundgren@xxxxxxxx on 6/4/2002 4:56 am wrote:
Lynn,
I don't believe (note, "believe" not know for sure), that this
where I see the market go.
I.e. I don't believe that TTP CAs issuing one-to-many credentials,
should ever be liable for anything but their own activities
including the identity of the certified entity. For the latter that
liability is likely to be only in the range of $10000-$100000.
If you need more you will have to pay a big premium. And if
relying parties require more, they will get no customers.
Identrus is though heading your way but I have not [yet] seen
any signs of the B2B-industry buy into their lawyer-centric stuff.
VeriSign is good enough and is much easier to buy.
I don't really see we have a problem with B2B-PKI except that
business systems do not support PKI. I.e. their "account records"
has neither support for certificates nor for public keys.
=========================================
But I know that you think differently and so do many PKI
promotors. I still think we have not seen the winner yet.
Status quo beats PKI and AADS by a mile. Unfortunately.
=========================================
Although interesting, we'd better terminate this thread and
give room for other interesting payment-related stuff.
Proposed subject: What does P-Cards have for "reason to live"
in an on-line society? My answer: null. 3D Secure et al
makes centrally maintained profiles a thing of the past.
Anders
Credit card fraud sending night-vision rifle scope to criminal
From: Lynn Wheeler
Date: 06/06/2002 04:18 AM
To: epay@xxxxxxxx
Subject: Credit card fraud sending night-vision rifle scope to criminal
http://www.csmonitor.com/2002/0605/p01s04-wome.html
Microsoft Trustbridge ... Kerberos (tickets) support
From: Lynn Wheeler
Date: 06/06/2002 01:31 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Microsoft Trustbridge ... Kerberos (tickets) support
http://news.com.com/2100-1001-933297.html?tag=fd_top
note that pk-init draft (rev 15 recently expired and draft 16 is yet
to go up) specifies initial authentication to kerberos server via
public key mechanisms.
AADS Chip Strawman & aSuretee
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 08/01/2002 12:58 PM
To: epay@xxxxxxxx
cc: 'Internet-Payments' <internet-payments@xxxxxxxx>
Subject: AADS Chip Strawman & aSuretee
I mentioned several times over the past four years the AADS Chip
Strawman that I had been working on (for strong authentication)
https://www.garlic.com/~lynn/x959.html#aads
I also gave a talk on it at the Intel Developer's Forum last year,
including a claim that pretty much as it currently existed, it could
do all the things that were requirement for trusted computing
module. A copy of this presentation is also at the above URL (slides
on assurance).
ATM Scams - Whose Liability Is It, Anyway?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 08/13/2002 09:50 AM
To: epay@xxxxxxxx, internet-payments <internet-payments@xxxxxxxx>
Subject: ATM Scams - Whose Liability Is It, Anyway?
--ATM Scams - Whose Liability Is It, Anyway?
American Banker Tuesday, August 13, 2002
By David Breitkopf
As the topic of fraud at automated teller machines commands increasing
attention, some observers fear that conflicting interests among the
banks and vendors involved - particularly over liability - will snarl
industrywide efforts to correct the problem.
Bankers say they have only begun to understand the range of problems
associated with skimming.
"It's uncharted territory right now," said Robin Nenninger, the
executive vice president and manager of ATM operations at
U.S. Bancorp. "I do think you'll be looking closer at the contracts to
decide where the ultimate liability lies. You want to protect
yourself, but you also want to solve it for the industry."
Henry Polmer, a partner at the law firm Piper Rudnick LLP in
Washington, is part of a task force examining the matter. "Everyone
wants to cure the problem, but what happens if there's a large loss?"
he asked. "Who's liable? At some point, there could be
finger-pointing."
On July 23 the Electronic Funds Transfer Association organized a
meeting of nearly every interested party to work on collective
solutions, specifically to the growing problem of skimming. This type
of fraud involves stealing PIN numbers and other card data, often
through devices attached to the machines, and using the data either to
manufacture fraudulent cards or to loot bank accounts.
Because many of the entities represented at the meeting had
conflicting interests, Mr. Polmer and others expressed concern that
the "ATM Integrity Task Force" that was set up at the meeting might
not be able to sustain a united front.
"The potential for disputes between the parties over their liabilities
to each other lies just below the surface," he said.
The task force includes officials from ATM manufacturers, banks,
independent sales organizations, the card associations, electronic
funds transfer networks, software companies, and law
enforcement. Since skimming could be fostered by negligence on the
part of any of the entities involved in a transaction - from the
card-issuing bank all the way back to the ATM manufacturer - all
manner of finger-pointing is possible.
Complicating the situation is a patchwork of regulations governing
these transactions, along with the fact that law enforcement is
reluctant to pursue skimming thefts unless the amounts involved are
substantial.
Consumers who report unauthorized transactions to their card issuers
in a timely fashion are made whole by their bank and protected against
losses by the EFT Act, the Federal Reserve's Regulation E, and card
association rules such as zero liability.
Nevertheless, consumers could be vulnerable to identity theft, which
could destroy their creditworthiness for years. Identity-theft victims
complain that local police departments tend to be powerless to help
them and that working with federal law enforcement tends to be
difficult.
Though issuers are the first to take the hit when consumer accounts
are attacked, network rules can make the merchant-acquirer or ISO
liable to the issuer if account data and PINs were not properly
encrypted at the ATM. Nonbank ATM owners and ISOs, in turn, may be
contractually liable to the merchant-acquiring bank.
"Of course, everyone turns ultimately to the ATM manufacturers to see
whether they have accurately certified the compliance of their
machines with network rules," said Mr. Polmer.
At the task force meeting, a number of members said that it is nearly
impossible to locate a machine at which a fraud was perpetrated.
One of the suggested solutions was to give ATMs identification numbers
- similar to the vehicle identification numbers on cars - so the
machines could be more easily tracked. However, that alone would not
guarantee that law enforcement would be able to determine which ATM
has been compromised.
Card-issuing banks in particular are interested in being able to
identify which machines were used in the crime to help determine
liability.
"If they know whose ATMs caused those cards to be compromised, then
the cardholder's bank will be able to allege that machine was not
secure," Mr. Polmer said. Otherwise, the issuing bank would end up
paying for the fraud, he said.
If the issuing bank could identify the acquiring bank responsible for
the ATM, the acquiring bank would then seek to move the liability
further down the food chain, often to the ISO that deployed the
machine.
H. Kurt Helwig, the executive director of the Electronic Funds
Transfer Association, of Herndon, Va., said the task force did not
want to discuss the potentially divisive issue of liability.
"I don't look at the task force as a vehicle to discuss liability
issues," he said. "I suspect the attorneys of those companies will be
dealing with those problems, but I think the goal of the task force is
to work together to solve the issue or control it."
Nandita Bakhshi, the director of the deposit/payment product group for
FleetBoston Financial Corp., said the question of liability remains
cloudy. "I don't think we've gotten a good answer yet. That's an
issue that needs to be discussed between the issuing banks, the
acquiring bank, and the EFTA and the networks. These are evolving
things. I don't think people anticipated these types of issues."
The weakest link in the liability chain could be the ISOs, the
companies that put the ATMs or help finance the placement.
"Quite frankly, we're the last throat to choke," said Lance Setliff,
the national sales manager for Momentum Cash Systems Inc., a Houston
ISO.
Mr. Setliff said he doubts the merchants whose stores house the ATMs
would be held liable, because most do not have enough money to cover
the funds that a skimmer could steal. Last year, for example, a scam
in New York netted about $3.5 million in only a few weeks.
Momentum Cash says that in recent months it has gotten much tougher
about screening the people it hires as "dealers" to make arrangements
with merchants. However, the ISO says that the rise of skimming was
only one of the factors in its decision. Another is the spectacular
bankruptcy last year of the Philadelphia-based Credit Card Center, the
largest ISO in the United States, which made many merchants wary of
doing business with ISOs, Momentum Cash says.
"We talked to merchants, and merchants know about that," Mr. Setliff
said. "We took a black eye."
FSTC Announces Proximity Payment Trial
From: Lynn Wheeler
Date: 08/15/2002 04:11 PM
To: epay@xxxxxxxx
Subject: FSTC Announces Proximity Payment Trial
To FSTC Members and Friends
From Jim Salters, Director of Project Development, FSTC
The full project proposal and letter of intent can be downloaded at
http://fstc.org/projects/new.cfm#infrared
Questions and letters of intent should be directed to me
(jim.salters@xxxxxxxx) or Zach Tumin (zachary.tumin@xxxxxxxx).
___________________
Executive Summary
- Overview
FSTC proposes an initiative for its member financial institutions and
technology companies to participate in the USC and Harex InfoTech
Wireless Mobile Payments Trial. The trial will create a live commerce
environment in which infrared-based (and RFID-based if desired)
devices will be deployed, and user acceptance and behavior studied.
FIs have the option of participating operationally in the test, in
addition to directing the research.
- Deliverables
The following are the deliverables to be produced as a result of
completing the Project
- A design and implementation of an electronic issuing system for
wireless proximity payments at USC, scalable for commercial release
- A report researched and prepared by USC's Marshall School of
Business documenting customer/user acceptance issues in the use of
infrared and/or RFID payment devices among USC students and staff
- A document detailing the issuing system requirements sufficient
for large-scale commercialization of electronic issuing for wireless
proximity payment
- Participation Requirements
Total project budget is $576,000. FSTC members will be responsible for
approximately 25%, or $148,000. Assuming that four financial
institution participate, the cost per (FI) participant is $37,000 per
member.
- Participation Benefits
Participating FIs will leverage a $576,000 project with a $37,000
investment, and gain/receive
- Research products valued at 5-6 times the purchase price
- Invaluable experience implementing the infrared/RFID payment system
- Customer contacts/touch/relations as issuer with USC students and staff
- Implementation Dates
The target project start date is August 27th, 2002, and will run
September - June 2002/3.
RFC3354 Internet Open Trading Protocol Version 2 Requirements
From: Lynn Wheeler
Date: 08/15/2002 05:06 PM
To: epay@xxxxxxxx,: internet-payments@xxxxxxxx
Subject: RFC3354 Internet Open Trading Protocol Version 2 Requirements
A new Request for Comments is now available in online RFC libraries.
RFC 3354
Title: Internet Open Trading Protocol Version 2 Requirements
Author(s): D. Eastlake, III
Status: Informational
Date: August 2002
Mailbox: Donald.Eastlake@xxxxxxxx
Pages: 6
Characters: 9671
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-trade-iotp2-req-02.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3354.txt
This document gives requirements for the Internet Open Trading
Protocol (IOTP) Version 2 by describing design principles and scope
and dividing features into those which will, may, or will not be
included.
Version 2 of the IOTP will extend the interoperable framework for
Internet commerce capabilities of Version 1 while replacing the XML
messaging and digital signature part of IOTP v1 with standards based
mechanisms.
This document is a product of the Open Trading Protocol Working Group
of the IETF.
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Credit Card Skimming Rising In The US
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/05/2002 08:53 AM
To: epay@xxxxxxxx, internet-payments <internet-payments@xxxxxxxx>
Subject: Credit Card Skimming Rising In The US
Credit Card Skimming Rising In The US
Bankrate.com
May 29 2002 : Losses to credit card skimming exceed USD 1 billion per
year, and occur "anywhere credit cards are put into a point-of-sale
database", due to transparent technology, says Brian Marr, of the US
Secret Service. A skimmer acts "as a net [in taking] information off
the card", Marr explains, and traps data from hundreds of credit
cards, to "be downloaded into a computer and e-mailed anywhere in the
world". In the past three years, skimmers have shrunk in size and are
widely available online, whereas criminals previously "had to make a
skimmer [themselves]", says Lou Struett, of Magtek, a manufacturer of
mag-stripe card readers.
Card skimming is a big problem in Europe, Asia and Latin America, with
Hypercom's George Wallner noting, "a Far East factory will do as many
as 5,000 cards a night, and the next day those cards are in a suitcase
on the way to Europe". Skimmers are available online from USD 300, and
equipment to make a counterfeit credit card costs USD 5,000 to USD
10,000, and thieves can also slip a 'skimming bug' into an older
credit card terminal, to retrieve the card data a few days later. In
the US, a scam ring surfaced in April, in which two waitresses at an
Orlando restaurant sold credit card data to a crime ring in Miami.
In a separate, "atypical" case, Hampton police charged an individual
with credit card theft for opening a series of fake businesses and
respective bank accounts. The man "also obtained a POS terminal" and
"hundreds of credit card numbers", the Daily Press reports, "and in
the evening, he would sit down and rack up sales with these businesses
through this POS terminal, putting those sales into his
accounts". Next day, he would "go around the different banks ...and
withdraw funds against these sales", some of which exceeded USD 50,000
in one day, but the sharing of data by five different banks led to his
arrest.
The major credit card firms, and technology vendors, are addressing
the issue of skimming with new procedures and products designed to
minimize the risk of card fraud. Migrating to chip-based cards under
the EMV initiative will eliminate many of the problems associated with
the cloning of payment data from a mag-stripe card, while the
upgrading of POS terminals to accept chip-based transactions,
eliminates the risk of terminals being 'bugged'. Gartner analyst,
Jeff Roster, also believes that if POS terminals, such as Trintech's
eVia terminal, are brought to tables in restaurants, the overall rate
of skimming would drop.
Credit card theft feared in Windows flaw
From: Lynn Wheeler
Date:09/06/2002 08:16 AM
To: epay@xxxxxxxx, internet-payments <internet-payments@xxxxxxxx>
Subject: Credit card theft feared in Windows flaw
http://news.com.com/2100-1001-956729.html
x9.73 Cryptographic Message Syntax
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/27/2002 09:12 AM
To: epay@xxxxxxxx
Subject: x9.73 Cryptographic Message Syntax
X9.73 reconsideration is being finalized.
It references RFC 2630, CMS ... which has been obsoleted by 3369 (which
also obsoletes RFC 3211)
3369 PS
Cryptographic Message Syntax (CMS), Housley R., 2002/08/30 (52pp)
(.txt=3D113975) (Obsoletes 2630, 3211) (was
draft-ietf-smime-rfc2630bis-08.txt)
there is also at the same time
3370 PS
Cryptographic Message Syntax (CMS) Algorithms, Housley R., 2002/08/30
(24pp) (.txt=3D51001) (was draft-ietf-smime-cmsalg-08.txt)
there is also:
3278 I
Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic
Message Syntax (CMS), Blake- Wilson S., Brown D., Lambert P., 2002/04i/30
(16pp) (.txt=3D33779) (was draft-ietf-smime-ecc-06.txt)
... i have a IETF RFC standards index at:
https://www.garlic.com/~lynn/rfcietff.htm
from an x9.59 standpoint there is section 6.2 on Signed Data. and
6.2.5
Detached Signatures.
In the mapping of x9.59 to ISO 8583 an optimized transport was
suggested which uses existing ISO8583 transport values with just the
additional information needed to reconstruct & validate the senders
signing.
from an 8583 perspective, effectively iso 8583 fields along with some
additional values are marsheled into a block foi signing. The
suggested use was fips186-2, ecdsa digital signature. A standard 8583
message then had the additional values and the digital signatures
combined in a normal 8583 "addenda" field. The relying party
(typically the consumer's issuing institution) receives the 8583
message and reconstitutes the originally signed message to perform the
signature verification. In this scenario, the actual signed message
is not transmitted in the original "signed format". The suggested
mapping of X9.59 to iso 8583 eliminates the redundant transmission of
elements in a standard iso 8583 message as well as eliminating any
superfluous values not needed for the 8583 transaction and the
verification of the signature on the transaction.
Fitting x9.59 specification suggested mapping to iso 8583 within the
context of the x9.73 specification can either be viewed as a) detached
signature (under 6.2.5) or possibly use the Signed Data format for
signing and verification but not for actual transmission. Within the
context of the x9.59 suggested mapping to iso 8583, certificates are
redundant and superfluous when the public key has been registered with
the consumer's
financial institution. The 6.2 Signed Data format allows that the
certificate related material is OPTIONAL but there is:
SignerInfos ::= SET OF SignerInfo
SignerInfo ::= SEQUENCE {
version Version (v1 | v3, ...),
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] UnsignedAttributes OPTIONAL
}
values which are nearly all fixed in the suggested x9.59 mapping
except for "sid".
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
certHash [73] EXPLICIT Hash
}
The verbage for the sid field is
The sid field of SignerInfo identifies the signer's certificate. This
standard provides three alternatives for identifying the signer's
public key issuerAndSerialNumber, subjectKeyIdentifier, and
certHash. The issuerAndSerialNumber alternative identifies the
signer's certificate by the issuer's distinguished name and the
certificate serial number; the subjectKeyIdentifier identifies the
signer's certificate by the X.509 subjectKeyIdentifier extension
value; and the certHash identifies any certificate format.
==============
In the x9.59 to iso 8583 mapping, the public key has been registered
with the consumer's financial institution, the consumer's financial
instituion certifies that public key and registers it in the
consumer's account record. There is two choices at this point, either
1) add a new choice for SignerIdentifier which indicates retrieve
certified public key from consumer's account record, where the
identification of the account record is included in the body of the
transaction ... say something like "IssuerAccountNumber".
2) create a convention for interoperation of x9.59 mapping to iso 8583
within the CMS specification that "certHash" identification of any
certificate format .... is an "account format" certificate (in this
context). this account record is similar to a certificate LDAP
operation ... except it occurs implicitly within the construct of an
existing business process that is retrieving the record (although
there could be provisions for realtime LDAP retrieval for non-legacy
operations).
IBM launches smart-chip consultancy - Tech News - CNET.com
From: Lynn Wheeler
Date: 09/28/2002 07:10 AM
To: epay@xxxxxxxx
Subject: IBM launches smart-chip consultancy - Tech News - CNET.com
http://news.com.com/2100-1001-959991.html?tag=fd_top
Government of Canada Public Key infrastructure
From: Lynn Wheeler
Date: 10/12/2002 05:29 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Government of Canada Public Key infrastructure
http://www.cio-dpi.gc.ca/pki-icp/index_e.asp
Finance firms push messaging standards
From: Lynn Wheeler
Date: 10/16/2002 12:55 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Finance firms push messaging standards
http://news.com.com/2100-1023-962284.html?tag=fd_top_1
October 16, 2002, 11:25 AM PT
Seven top brokerage firms on Wednesday formally announced a coalition
to promote the adoption of standards in the fragmented instant
messenger industry.
As previously reported, financial services firms, including Deutsche
Bank and J.P. Morgan Chase, this summer formed the Financial Services
Instant Messaging Association (FIMA), formerly known as the Instant
Messaging Standards Board (IMSB). The committee, which also includes
representatives from Credit Suisse First Boston, Lehman Brothers,
Merrill Lynch, Morgan Stanley, and UBS Warburg, publicly touted its
lofty goal of fostering technical harmony among IM providers Yahoo,
AOL, MSN and others
glossary
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/19/2002 09:18 PM
To: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: glossary
I've done quite a few additions (over the past couple months) to the
merged security glossary at
https://www.garlic.com/~lynn/index.html#glossary
up to date description
https://www.garlic.com/~lynn/index.html#glosnote
while the financial glossary is quite large .... i've been trying to
get approval to include the most recent BIS (basel) glossary merged
into the financial glossary. So far I haven't been able to find a
contact to say one way or another. if anybody is knows of a contact at
BIS that might be in position to approve the merginng of their
glossary into my financial glossary, I would appreciate it.
bis is at:
http://www.bis.org/index.htm
glossary at:
http://www.bis.org/publ/cpss00b.htm#pgtop
San Diego Company owns e-commerce
From: Lynn Wheeler
Date: 10/23/2002 06:37 PM
To: epay@xxxxxxxx
cc: internet-payments@xxxxxxxx
Subject: San Diego Company owns e-commerce
from:
http://yro.slashdot.org/yro/02/10/23/197234.shtml?tid=155
Kernel Panic writes Looks like you can now be sued for using
graphical and textural content on your e-commerce site. As everyone
who has an e- commerce site does. A company in San Diego was granted
one patent for using graphics and text to sell things on the web and
another for accepting information to conduct automatic financial
transactions via a telephone line & video screen. They have started
their crusade with smaller companies that do not have the financial
resources to fight back so as to build a "war chest" to take on larger
companies like Ebay and Amazon. One site has taken the offense after
becoming one of the first defendants of 50 companies so far. Curiously
it appears the company was formed in March of 2002, less than a month
before filing for the first lawsuit.
REVIEW: "Secure XML", Donald E. Eastlake/Kitty Niles
From: Lynn Wheeler
Date: 10/24/2002 03:14 PM
To: epay@xxxxxxxx
Subject: REVIEW: "Secure XML", Donald E. Eastlake/Kitty Niles
Date: Tue, 22 Oct 2002 07:15:08 -0800
From: Rob Slade <rslade@xxxxxxxx>
Subject: REVIEW: "Secure XML", Donald E. Eastlake/Kitty Niles
BKSECXML.RVW 20020831
"Secure XML", Donald E. Eastlake/Kitty Niles, 2003, 0-201-75605-6,
U$44.99/C$69.99
%A Donald E. Eastlake III
%A Kitty Niles
%C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8
%D 2003
%G 0-201-75605-6
%I Addison-Wesley Publishing Co.
%O U$44.99/C$69.99 416-447-5101 fax: 416-443-0948
%P 532 p.
%T "Secure XML: The New Syntax for Signatures and Encryption"
Part one is introductory material. Chapter one is about XML
(eXtensible Markup Language), but is not very clear, especially in
regard to the relationship between XML, SGML (Standard Generalized
Markup Language), and HTML (HyperText Markup Language). Security
concepts do not play a big part. The tutorial on cryptography, in
chapter two, is very simplistic, uses obtuse language, and is much
harder on the reader than is really necessary.
Part two deals with the basics of XML. Chapters three through eight
present some of the syntax and structure of XML documents, DTDs
(Document Type Definitions), Schemas (particularly unclear), XPath,
XPointer, and SOAP. That is about all they provide: the material is
not helpful in explaining uses, or how the parts fit into a framework
or package.
Part three covers canonicalization and authentication.
Canonicalization is important to authentication, as chapter nine
points out, because it allows us to eliminate meaningless differences
between essentially the same file, as when different file systems use
varying newline characters or sequences. Ordinarily, such differences
would result in differences in hash code results, and therefore a
false failure of authentication. Chapter ten outlines signature
syntax, while eleven talks very briefly about the XMLDSIG standard for
digital signatures, and twelve reviews the European Telecommunications
Standards Institute's (ETSI) somewhat more advanced signatures.
Part four looks at keying, with the KeyInfo element in chapter
thirteen, and XKMS key management in fourteen. Chapter fifteen, on
the proposed XMLENC standard, and sixteen, containing some discussion
of combinations of encryption and signatures, make up part five. Part
six, entitled "Algorithms," reviews algorithm specification, in
chapter seventeen; available algorithms, in eighteen; and related non-
cryptographic algorithms, in nineteen.
The writing is turgid, almost deliberately dense, and fails to provide
necessary tutorial details. Those who are well familiar with XML will
find some particulars regarding the specific encryption documents, but
few others will find the work useful.
copyright Robert M. Slade, 2002 BKSECXML.RVW 20020831
rslade@xxxxxxxx rslade@xxxxxxxx slade@xxxxxxxx p1@xxxxxxxx
http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
First International Conference On Trust Management
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date; 11/04/2002 05:46 PM
To: epay@xxxxxxxx
Subject: First International Conference On Trust Management
++++++++++++++++ CALL FOR PAPERS ++++++++++++++++++++
The First International Conference
On Trust Management
28-30 May 2003
Heraklion, Crete, Greece
(http://www.eBusinessCity.org)
The First International Conference on Trust Management will take place
at the beautiful summer resort Kalimera Kriti (Good Morning Crete)
(http://www.kalimerakriti.gr/) near Heraklion, Crete, Greece, on May
28-30 2003. The Conference is organized by iTrust, a Working Group on
Trust Management in Dynamic Open Systems (http://www.itrust.uoc.gr/)
and the University of Crete (http://www.uoc.gr) and partially funded
by the Future and Emerging Technologies (FET) unit of the IST program
(http://www.cordis.lu/ist/fethome.htm).
The Proceedings will be published by the Lecture Notes in
Computer Science (LNCS) series of Springer Verlag,
http://www.springer.de/comp/lncs/index.html
Its purpose is:
To facilitate the cross-disciplinary investigation of fundamental
issues underpinning computational trust models by bringing together
expertise from technology oriented sciences, law, philosophy and
social sciences.
To facilitate the emergence of widely acceptable trust management
processes for dynamic open systems and applications
To facilitate the development of new paradigms in the area of dynamic
open systems which effectively utilise computational trust models.
To help the incorporation of trust management elements in existing
standards
Papers, short papers, panel, special session and tutorial proposals
are solicited in the following list of areas which is indicative and
not exhaustive:
- The ethics, sociology and psychology of trust
- Cyberspace freedom vs. safeguarding consumer confidence and trusting
relations.
- Legal issues underpinning the management of trust
- Trust in Contract, service level agreement negotiation and management,
organizational networks
- Models and semantics of trust
- Trust specification, analysis and reasoning
- Trust based on recommendation and reputation
- Design of trust based architectures and decision-making mechanisms for
e-community and e-service interactions
- Monitoring trust
- Relationship between trust and risk
- Relationship between trust and security
Keynote Speaker
Stuart Feldman, IBM VP Internet Technology, USA
Program Committee ( means confirmation pending)
Christos Nikolaou, U. of Crete, Greece, Conference Chair
Paddy Nixon, U. of Strathclyde, UK, Program Chair
Nikos Alivizatos, U. of Athens, Greece
Eliza Bertino, U. of Milano, Italy
Jon Bing, NRCCL, U. of Oslo, Norway
Joan Borrell, Autonomous University of Barcelona, Spain
Cristiano Castelfranchi, CNR, Italy
Stefano Cerri, U. of Montpellier II, France
Theo Dimitrakos, CLRC, UK
Valerie Issarny, INRIA, France
Keith Jeffery, CLRC, UK
Christian D. Jensen, Trinity College, Ireland & DTU, Denmark
Andrew Jones, King's College, UK
Audun Josang, DSTC, Australia
Graham Klyne, Nine by Nine, UK
Heiko Krumm, U. of Dortmund, Germany
Manolis Marazakis, Plefsis, Greece
Stefan Poslad, Queen Mary College, UK
Dimitris Raptis, Intracom, Greece
Jakka Sairamesh, IBM Research, USA
Giovanni Sartor, U. of Bologna, Italy
Simon Shiu, Hewlett Packard, UK
Morris Sloman, Imperial College, UK
Ketil Stoelen, SINTEF, Norway
Yao-Hua Tan, Free University of Amsterdam, Holland
Sotirios Terzis, U. of Strathclyde, UK
Dimitris Tsigos, Virtual Trip Ltd, Greece
Stavroula Tsinomera, U. of Crete, Greece
Emily Weitzenboeck, NRCCL, U. of Oslo, Norway
Paper Submission
Papers should be submitted electronically in PDF, HTML or MS-Word
format, either by e-mail to the Conference Secretariat
(info@xxxxxxxx ) or to our ftp site
(ftp://ftp.eBusinessCity.org).
In either case, please follow the guidelines below:
1.In your submission, there should be only one file containing
the paper text, suitable for review printing (maximum 20 printed
pages with font size not less than 10pt).
2.Each figure (or other material except text) should be in a
separate file
3.All files consisting your paper should be gathered in a
single file (zip or tar format)
4.Submit your paper either by e-mail or ftp (please note that
electronic submissions are obligatory)
5.Send a separate e-mail message to info@xxxxxxxx containing
the paper title, abstract, keywords and any relevant contact information.
All accepted papers for the conference will be published by the LNCS
series of Springer-Verlag. Please consult the Authors Instructions
subpage (http://www.springer.de/comp/lncs/authors.html) as well as to
the Editors Instructions subpage
(http://www.springer.de/comp/lncs/editors.html) on the LNCS Home Page
where answers can be found to most technical questions.
Short Papers
During the conference a space will be reserved for short paper
sessions. Research projects of any scale are invited to illustrate
innovative concepts and prototype systems.
Short paper proposals should include title, names of presenters and
outline (max. 500 words). Electronic submissions are obligatory;
proposals should be submitted by e-mail to the Conference
Secretariat, info@xxxxxxxx
Panels/Special Sessions chair
Christian D. Jensen, Trinity College, Ireland & DTU, Denmark
Suggestions for the organisation of panel sessions on one of the
proposed topics or on related topics are welcomed. Proposals should
include a short CV and position paper for each panellist, and should
be sent to Christian.Jensen@xxxxxxxx
Tutorial chair:
Theo Dimitrakos, CLRC, UK
Proposals for tutorials are solicited. Tutorials would be either half
day (3 hours) or full day (6 hours). Each proposal should include a
title, a summary (intentions, objectives, etc.), duration and a short
CV of the instructor(s) and should be sent to T.Dimitrakos@xxxxxxxx
Demo chair:
Dimitris Tsigos, Virtual Trip Ltd, Greece
Result demonstrations of on-going projects are strongly
encouraged. Those interested should submit a description of the
intended Demo to tsigos@xxxxxxxx
Local Organizing Committee
Christos Nikolaou, U. of Crete, Chair
Eva Michelidaki, U. of Crete, Dissemination
Calliope Anagnostopoulou, U. of Crete, Local accommodations
Shore Shadman, U. of Crete, Registration
Kyriakos Papadakis, U. of Crete, Webmaster
Michalis Klisarchakis, U. of Crete, Webmaster
Vasilis Poursalidis, U. of Crete, Networking & Systems
Elias Theoharopoulos, U. of Crete, Networking & Systems
Important Dates
Submission of papers: January 6
Submission of panel or special session proposal: March 30
Submission of tutorial proposal: March 30
Submission of demo proposal: March 30
Notification of panel or special session acceptance: April 15
Notification of tutorial acceptance: April 15
Notification of demo acceptance: April 15
Notification of paper acceptance: March 10
Submission of final version: March 31
GAO Government Agencies Adhering to Privacy Laws
From: Lynn Wheeler
Date: 11/04/2002 05:41 PM
To: epay@xxxxxxxx
Subject: GAO Government Agencies Adhering to Privacy Laws
On 30 Oct 2002, the General Accounting Office issued a report
"Information Management: Selected Agencies' Handling Of Personal
Information" finding that the Departments of Agriculture, Education,
Labor, and State generally adhere to government privacy laws. "The
report found that agencies' handling of information varies and that a
wide range of government personnel have access to the information, but
by and large, the agencies follow current privacy laws." (Information
considered included names, phone numbers, addresses, SSNs, financial
and legal data, and demographic information, provided for a specific
purpose such as to receive benefits, obtain services or loans, or
participate in a specific federal program.)
[Source: Eric Chabrow, InformationWeek, 30 Oct 2002; PGN-ed]
http://news.lycos.com/news/story.asp?section=Politics&storyId=556059
Meeting to mull privacy standard's next step
From: Lynn Wheeler
Date: 11/11/2002 05:26 PM
To: epay@xxxxxxxx
Subject: Meeting to mull privacy standard's next step
http://www.computerworld.com/securitytopics/security/privacy/story/0,10801,75814,00.html
Workship on Human/Computer Interaction and Security systems
From: Lynn Wheeler
Date: 11/11/2002 01:31 PM
To: epay@xxxxxxxx
Subject: Workship on Human/Computer Interaction and Security systems
http://www.iit.nrc.ca/~patricka/CHI2003/HCISEC/index.html
SAML Just The Start For Web Services Security
From: Lynn Wheeler
Date: 11/11/2002 09:45 PM
To: epay@xxxxxxxx
Subject: SAML Just The Start For Web Services Security
http://itmanagement.earthweb.com/columns/secugud/article/0,,2771_1498491,00.html
Cardtech/Securtech aSuretee press release
From: Lynn Wheeler
Date: 11/20/2002 08:30 AM
To: epay@xxxxxxxx
cc: internet-payments <internet-payments@xxxxxxxx>
Subject: Cardtech/Securtech aSuretee press release
http://www.firstdata.com/news_article.jsp?nID=1813
Liberty Alliance Waves White Flag at Passport
From: Lynn Wheeler
Date: 12/03/2002 06:19 AM
To: epay@xxxxxxxx
Subject: Liberty Alliance Waves White Flag at Passport
http://www.eweek.com/article2/0,3959,740753,00.asp
First Data Unit Says It's Untangling Authentication
From: Lynn Wheeler
Date: 12/06/2002 09:48 AM
To: internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: First Data Unit Says It's Untangling Authentication
AADS press release ... also
https://www.garlic.com/~lynn/x959.html#aads
http://www.firstdata.com/news_article.jsp?nID=1813
First Data Unit Says It's Untangling Authentication
From: Lynn Wheeler
Date: 12/09/2002 01:37 PM
To: internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: First Data Unit Says It's Untangling Authentication
cross-post thread from another mailing list:
https://www.garlic.com/~lynn/aadsm12.htm#50 Frist Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#51 Frist Data Unit Says It's Untangling Authentication
and somewhat related thread in sci.crypt ng:
https://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#10 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#12 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#17 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#18 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#20 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs', how curruptable are they to
VeriSign unveils new online identity verification services
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 12/11/2002 09:49 AM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: VeriSign unveils new online identity verification services
http://www.computerworld.com/securitytopics/security/privacy/story/0,10801,76558,00.html
Trust services vendor VeriSign Inc. today unveiled a new online
identity- verification service that allows Web customers to positively
establish their identities with online merchants.
The new Consumer Authentication Service (CAS) provides online
businesses with instant, round-the-clock information taken from more
than 50 public and private databases to ensure a customer's identity,
said Anil Chakravarthy, director of product management for VeriSign's
enterprise group.
The information comes from state motor vehicle department, government,
credit bureau and telephone number databases, Chakravarthy
said. Optimized scoring models are used to help businesses quickly and
easily determine whether potential buyers are who they claim to be.
The services, which are charged to the businesses on a per-
transaction basis by Mountain View, Calif.-based VeriSign, vary with
the importance of the identity checks.
The services aren't for typical retail online sales but could be used
by online auction houses such as eBay or similar businesses to
establish the identities of first-time customers seeking credit
accounts, Chakravarthy said.
"It makes very good sense for the online auction house to check on
you" to reduce fraud, identity theft and other problems, he said.
The new service uses a predefined set of XML standards to connect to
an enterprise's customer-facing Web application. The authentication
data entered by the consumer is then automatically routed using XML
and encryption through VeriSign's services and is checked against
varied databases to cross-verify and risk-rank the consumer identity
in real time. Verification is then automatically sent back to the
enterprise application and to the consumer, using underlying XML data.
The communication is secured with Secure Sockets Layer encryption that
is already built into standard Web servers and browsers.
"We take extraordinary measures not only to be highly secure ... but
also we take extraordinary care to ensure the privacy of this
information," Chakravarthy said.
VeriSign had previously offered such services only to online auction
vendors but is now making the services available to a broader
audience.
MaterCard test high-tech payments
From: Lynn Wheeler
Date: 12/13/2002 10:08 AM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: MaterCard test high-tech payments
http://news.com.com/2100-1001-977829.html?tag=fd_top
MasterCard tests high-tech payments
By Alorie Gilbert
Staff Writer, CNET News.com
December 13, 2002, 8:01 AM PT
MasterCard is testing a new credit-card system designed to speed the
payment process at check-out counters and replace cash transactions at
places such as movie theaters and fast food restaurants.
The system, called MasterCard PayPass, allows consumers with specially
equipped credit cards to simply tap or wave their cards against a
reader to make a payment, rather than having to swipe the card. If the
value of the purchase is under a certain amount, the cardholder
needn't sign a receipt.
The cards come embedded with hidden computer chips and radio antennae,
which transmit payment details wirelessly. The cards can also be used
with traditional magnetic stripe readers.
... snip ...
eBay Customers Targetted by Credit Card Scam
From: Lynn Wheeler
Date: 12/13/2002 10:12 AM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: eBay Customers Targetted by Credit Card Scam
http://news.bbc.co.uk/1/hi/business/2564725.stm
eBay Customers Targetted by Credit Card Scam
By Stefan Armbruster
BBC News Online business reporter
The world's largest online auction site eBay has been targeted by
fraudsters using a shadow site to steal credit card details from its
55 million customers.
The scam involved sending e-mails to customers asking them to log on
to a Florida-based website - ebayupdates.com - and re-submit their
financial details.
... snip ...
eBay Customers Targetted by Credit Card Scam
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/14/2002 01:44 PM
To: Drsmith <drsmith@xxxxxxxx>
cc: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: eBay Customers Targetted by Credit Card Scam
note that the aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads
has definitions that supports signing all financial transactions
... aka part of the task given the x9a10 working group for x9.59
payment standard was all retail payments (not just internet, not just
face-to-face, not just pos, not just non-face-to-face, not just
credit, not just debit, not just stored-value, ... but ALL) ...
https://www.garlic.com/~lynn/x959.html#x959
and also piloted in the NACHA debit network trial
.... pointer at:
https://www.garlic.com/~lynn/x959.html#aads
basically some amount of AADS has focused on standards
support for FIPS186-2, ecdsa/x9.62 digital signature standard as means
of authentication ... and the aads chip strawman basically focused on
just doing FIPS186-2, ecdsa/x9.62 digital signing. Note that the
standards activity of having FIPS182-2, ecdsa/x9.62 digital signature
standard as means of authentication doesn't mandate that it be done
with a hardware token. the protocol specification of FIPS186-2/x9.62
authentication is independent of the environment that performs the
signing. The issue of whether it is some PC software, or PDA software,
or hardware and/or what kind of hardware token is an integrity and
business issue. The protocol part can be common to all implementations
... and the end-point implementation then is purely a business &
integrity issue (1-factor, 2-factor, 3-factor authentication,
and/or integrity level of the components).
The other part is that possibly over 90 plus percent of the
internet-related authentication events occur with RADIUS ... aka
majority of the isps internets & corporate internets. aads
enhanced radius has been demo'ed a number of times
.... misc. discussions
https://www.garlic.com/~lynn/subpubkey.html#radius
Another major authentication process that goes on in the world today
is the kerberos based stuff supported by most of the operating system
platforms (and not solely internet). the original kerberos standard
has been shared-secret based ... however there is a draft standard to
extend it to include public key based authentication that includes
both certificate-based public key as well as certificate-less (aka
AADS) based public key
http://www.ietf.org/ids.by.wg/krb-wg.html
http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-16.txt
other discussions of upgraded the current certificate-based SSL public
key infrastructure to certificate-less based infrastructure:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
basically, any shared-secret, pin/password based infrastructure can be
upgraded by using the same business process ... but with a public key,
non-shared-secret based paradigm (and can all be supported by a single
asuretee hardware token).
for more information on kerberos
& radius authentication standards ... go to
https://www.garlic.com/~lynn/rfcietff.htm
and under RFCs listed by select Term (term->RFC#); from there
it is possible to select RADIUS from the Acronym fastpath .... aka
remote authentication dial in user service (RADIUS )
see also authentication , network access server ,
network services
3162 2882 2869 2868 2867 2866 2865 2809 2621 2620
2619 2618 2548 2139 2138 2059 2058
or scroll to kerberos
... aka:
kerberos
see also authentication , security
3244 3129 2942 2712 2623 1964 1510 1411
drsmith@xxxxxxxx on 12/14/2002 9:53 am wrote:
Those signing devices you refer to should not be limited to ecom.
Face to face transaction need something similar. "Who is this person
checking my signature and what qualification do they have?" I ask this
question every time, especially this time of year after the fear
mongering of the Associations to encourage checking of cards . We
should not limit solutions to one medium this creates differences in
our payment habits and further confuses the masses, lemmings that they
are. To find a secure solution that does not bridge multiple mediums
will go the path of SET.
eBay Customers Targetted by Credit Card Scam
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 12/14/2002 02:49 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: eBay Customers Targetted by Credit Card Scam
ref: previous posts
https://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
so another AADS based implementation is SSH .... i build a table of
acceptable public keys .... and then they can be used to
authenticate. so an enhancement to SSH would be to add fips186-2/x9.62
ecdsa support to standard SSH distribution. then you can use a
hardware token or a pda that supports simple fips186-2/x9.62 ecdsa
digital signatures to sign x9.59 financial transactions (all forms),
radius logins of your PPP connections (just about all ISP, DSL, dial,
etc), as well as all kerberos, and then ssh. nothing special in the
token needs to be aware of anything ... other than it is signing a
message ... and the same token can be used for everything that
requires a fips186-2/x9.62 ecdsa digital signature.
.... misc. ssh refs:
http://www.openssh.com/
http://archive.erdelynet.com/ssh-l/
http://www.ssh.com/
[IP] The 20th anniversary of the Internet (fwd)
From: Lynn Wheeler
Date: 12/15/2002 05:32 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: [IP] The 20th anniversary of the Internet (fwd)
somewhat related discussions :
https://www.garlic.com/~lynn/internet.htm#0
also for index of rfcs ... see
https://www.garlic.com/~lynn/rfcietff.htm
Date: Sat, 14 Dec 2002 14:02:54 -0500
Subject: [IP] The 20th anniversary of the Internet
From: Dave Farber <dave@xxxxxxxx>
To: ip <ip@xxxxxxxx>
Sender: owner-ip@xxxxxxxx
I still have the button and still have the memories of tht week djf
------ Forwarded Message
From: Bob Braden <braden@xxxxxxxx>
Date: Sat, 14 Dec 2002 10:08:38 -0800 (PST)
To: ietf@xxxxxxxx
Cc: internet-history@xxxxxxxx
Subject: The 20th anniversary of the Internet
We ought not to let pass unnoticed the impending 20th anniversary of
the Internet. The most logical date of origin of the Internet is
January 1, 1983, when the ARPANET officially switched from the NCP
protocol to TCP/IP. Six months later, the ARPANET was split into the
two subnets ARPANET and MILNET, which were connected by Internet
gateways (routers).
The planning for the January 1983 switchover was fully documented in
Jon Postel in RFC 801. The week-by-week progress of the transition was
reported in a series of 15 RFCs, in the range RFC 842 - RFC 876, by
UCLA student David Smallberg.
There may still be a few remaining T shirts that read, "I Survived the
TCP/IP Transition". People sometimes question that any geeks would
have been in machine rooms on January 1. Believe it!! Some geeks got
very little sleep for a few days (and that was before the work "geek"
was invented, I believe.)
So, on New Year's Eve, hoist one for the 20th anniversary of the
Internet.
Bob Braden
____________________________________________________
Routers brought to you by Bob Hinden of BBN.
Prominent survivors included Dan Lynch of Interop fame.
And of course Vint Cerf was working the Levers of Power at
ARPA.
Briwn gets creatuve with wireless
From: Lynn Wheeler
Date: 12/14/2002 05:48 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Briwn gets creatuve with wireless
http://news.com.com/2100-1033-977868.html?tag=fd_top
Brown gets creative with wireless
By Ben Charny
Staff Writer, CNET News.com
December 13, 2002, 1:06 PM PT
United Parcel Service said Friday it has stitched together a network
using two wireless technologies to speed package processing at
hundreds of its shipping hubs.
The shipping giant, which calls itself "Brown" in its advertising, is
beginning to deploy a tracking system that combines the Wi-Fi and
Bluetooth wireless technologies. Bluetooth can carry data over several
feet, while Wi-Fi has a 300-foot range, making it a popular method of
extending Net access in many homes and business.
UPS representative Ginnie Myhr said 55,000 package handlers eventually
will get Bluetooth bar code readers that are worn on the finger like a
ring. The ring scans a package label and sends the information to a
Wi-Fi radio attached to a handler's belt. The radio then sends the
information to a central computer.
UPS is testing the new system in four hubs, and it plans to install
the gear inside 1,700 U.S. package-sorting centers by 2004, Myhr said.
The system uses equipment built by Symbol Technology.
... snip ...
Who owns the methods of E-commerce?
From: Lynn Wheeler
Date: 12/16/2002 07:27 PM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Who owns the methods of E-commerce?
http://www.informationweek.com/story/IWK20021212S0010
Patenting The Process Dec. 16, 2002
Who owns the methods of E-commerce?
Many companies say they do and that they have the patents to prove it.
By John Soat
"Obviously, if all video on the Web infringes on their patent, you'd
think they'd go after the big guys, but they seem to be going after
little content providers who can't afford to fight them in court. I
can't help but feel like I'm being shaken down by the hi-tech version
of Tony Soprano. ..."
Strong words, even for a message board on the Internet. Mitigated,
perhaps, by the poster's nom de Web: Spooky Suicide. And when you find
out Mr. Suicide operates a (self-described) "slightly naughty" Web
site known as "Suicide Girls," you may begin to suspect there's more
than a little pot-versus-kettle syndrome at work here.
But this post is only one of many that have popped up over the last
several weeks, mostly in chat rooms and on message boards frequented
by operators of adult Web sites, in reaction to a company called
Acacia Media Technologies. Acacia has contacted the companies to
advise them that they're violating Acacia's patents for accessing or
downloading digital video and/or audio over the Internet, and they
must license the technology. Included in the communications are
explanations of the patents and a royalty schedule for
payments. Acacia has filed lawsuits alleging patent infringement
against 27 adult-entertainment companies, though none of the suits has
yet been served.
... snip ...
Web services specs focus on security
From: Lynn Wheeler
Date: 12/18/2002 08:11 AM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Web services specs focus on security
http://news.com.com/2100-1001-978314.html?tag=fd_top
Web services specs focus on security
By Martin LaMonica
Staff Writer, CNET News.com
December 18, 2002, 6:22 AM PT
A group of companies led by IBM and Microsoft on Wednesday published a
series of specifications designed to make Web services more secure.
The proposed specifications describe how companies can establish policies
on exchanging information among trading partners and how to make disparate
security systems interoperate. IBM and Microsoft co- authored the
specifications with input from a limited number of companies, including BEA
Systems, RSA Security and VeriSign.
The companies will incorporate industry feedback and submit the
specification to a standards body early next year, executives said.
... snip ...
Invisible Ink, E-signatures slow to broadly catch on
Refed: **, - **, - **
From: Lynn Wheeler
Date: 12/19/2002 04:50 PM
To: epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Invisible Ink, E-signatures slow to broadly catch on
http://cbs.marketwatch.com/news/story.asp?guid=%7B4CB87141%2D6DB9%2D427E%2DA46F%2DC0147B881307%7D&siteid=mktw
Invisible ink
E-signatures slow to broadly catch on
By Barbara Kollmeyer, CBS MarketWatch
Last Update: 1:26 AM ET Dec. 19, 2002
LOS ANGELES (CBS.MW) -The advent of electronic signatures heralded a
new age in online commerce -- a numeric code to replace an
individual's handwriting to register agreement.
Yet since President Clinton signed the Electronic Signature Act over
two years ago (see related story), indications are few companies are
taking full advantage. While little hard data exists, consumers have
been slow to embrace the technology due to fear of fraud and a lack of
understanding, experts said.
... snip ...
Invisible Ink, E-signatures slow to broadly catch on
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 07:43 AM
To: Ed Gerck <egerck@xxxxxxxx>
cc: "Robert E. Frank" <bobfrank@xxxxxxxx>, epay@xxxxxxxx,
internet-payments <internet-payments@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on
Forwarded from something I ran across somewhere else ....
Lets hypothesis an industry with a business model that every year they
would sell a shiny new $100 credential to every person in the world
... and are finding out that nobody is buying the credential.
Lets say that they go to business organizations and enlist them in
getting laws passed based on credentials being equivalent to human
signatures with the characteristics of non-repudiation (and
furthermore, everybody has to get one).
From the consumer's standpoint, non-repudiation means that in a
dispute the legal burden of proof is shifted from the merchant to the
consumer. Furthermore, the only thing that is necessary to achieve
this, is to define a new bit in the credential (and the new laws).
From the business standpoint ... the credential isn't costing them any
money ... the consumer is paying for it ... and it has the advantage
of shifting the burden of proof away from the business to the
consumer.
Some of the draft laws even refer to how all consumers are extremely
eager to participate in such wonderful new technology (they just can't
wait to get their shiny new credential every year and how shiny new
credentials make them feel so good and safe). It is like they don't
even have to perform a digital signature ... they just wave their
shiny credential over the bits and everything is just magically
blessed with non-repudiation and the burden of proof shifted to
themselves and how such actions just bring such uncontrollable joy to
their hearts.
Invisible Ink, E-signatures slow to broadly catch on
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 08:42 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Robert E. Frank" <bobfrank@xxxxxxxx>, "Ed Gerck" <egerck@xxxxxxxx>,
epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on
but it isn't the credential that magically enables all of that.
it is the business process behind what the credential represents that
is the actual enabler; as well as any trust in those background
business processes. That is totally separate from the additional
burden represented by establishing trust in the credentialling process
itself.
the credendtial just is used to represent the background business
process in an offline environment when there isn't direct access to
the real online business process.
much of the world has been migrating to online, all-the-time,
everywhere for some time.
The majority of the world today in financial related activities of
value are using online operations that directly link to the background
business processes in real time. Directly connecting to the background
business processes in real time for things of value makes the stale
representation by the credential redundant and superfluous.
Typically a credential can only represent a stale, static, much restricted
subset of information that is of interest in any transaction involving
value. Such value transactions typically are interested in not only
the subset of the information that might be represented by the (stale, static)
credential but also timely information that involves things like
aggregation and current status. It is left to operations of no value
and either incapable or not justified use of online environment (with
timely and/or aggregated information) that credentials can find a
market niche.
anders.rundgren@xxxxxxxx on 12/20/2002 8:17 am wrote:
Or put in another way ....
A credential issued through a global trust-network of banks
A credential allowing organizations to safely open their intranets
to the Internet
A credential eliminating the ocean of passwords that plague
users and help-desks
A credential that when revoked disables all access
A credential that when reissued restores all access
A credential that is conveniently carried in a mobile phone
A credential that allows you to pay, bank, identify, B2B, e-Gov etc.
... could maybe be worth some $25-$50 / Year
Anders
Invisible Ink, E-signatures slow to broadly catch on (addenda)
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 09:08 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
"Robert E. Frank" <bobfrank@xxxxxxxx>,
"Ed Gerck" <egerck@xxxxxxxx>, epay@xxxxxxxx,
"internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
... and for market niche of no or little value .... it would be
difficult to justify charging very much for a credential that is only
enabling no/little value operations/transactions. If very little is
being charged for a no/little value credential ... it would be
somewhat difficult to fund an expensive background business process
(for representation by the credential). Typically highly trusted
business process cost more than no-trusted business process. So the
correllary is likely to be that inexpensive, little/no-value
credentials for use in little/no-value transactions are likely to have
little (business process) trust.
Looking at it from the reverse viewpoint, transactions of value today
are using online access to the real backroom business process because
the timeliness and quality of the information (including things like
up-to-date aggregated information) subsumes the function of having a
stale, offline representation. The issue can be viewed as a risk
cost/benefit proposition. Timely, online access to the real backroom
business processes is likely to cost more than using an offline, stale, static
paradigm. The risk of performing a transaction with stale, static, offline
information is higher than real timely access to online information.
The issue is that as online all-the-time, everywhere becames less
expensive and more pervasive, the niche for stale, static offline credential
operations becomes smaller. In otherwards, it becomes easier and
easier to justify the cost of an online oriented paradigm for value
operations as online paradigm becomes less expensive and more
pervasive.
lynn.wheeler@xxxxxxxx on 12/20/2002 8:42 am wrote:
but it isn't the credential that magically enables all of that.
it is the business process behind what the credential represents that
is the actual enabler; as well as any trust in those background
business processes. That is totally separate from the additional
burden represented by establishing trust in the credentially process
itself.
the credendtial just is used to represent the background business
process in an offline environment when there isn't direct access to
the real online business process.
much of the world has been migrating to online, all-the-time,
everywhere for sometime.
The majority of the world today in financial related activities of
value are using online operations that directly link to the background
business processes in real time. Directly connecting to the background
business processes in real time for things of value makes the stale, static
representation of the credential redundant and superfluous.
Typically a credential can only represent a stale, static, much restricted
subset of information that is of interest in any transaction involving
value. Such value transactions typically are interested in not only
the subset of the information that might be represented by the (stale)
credential but also timely information that involves things like
aggregation and current status. It is left to operations of no value
and either incapable or not justified use of online environment (with
timely and/or aggregated) information that credentials can find a
market niche.
Invisible Ink, E-signatures slow to broadly catch on (addenda)
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 10:32 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: "Robert E. Frank" <bobfrank@xxxxxxxx>, Ed Gerck <egerck@xxxxxxxx>,
epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
OCSP only tells you whether the certificate information is valid or
not.
lets say it is a financial transaction.
the financial transaction wants to know the current balance or credit
limit (which is a real-time aggregated amount .... i.e. some previous
value plus all transactions todate).
so in a certificate world ... we put the current bank amount and/or
current credit limit in the certificate (ignore for the moment the
privacy issues).
the merchant gets the certificate ... and then does the OCSP
.... which is the chance the current, real-time value is in any way
related to the stale, static value deposited in the credential.
So we now have progress:
we can do away with the credential all together ... and always just do
the OCSP ... and the OCSP doesn't actually have to say what the
current credit or balance is ... it just has to say whether the
transaction is approved or not (addressing some serious privacy issues
in placing current balance/limit in a certificate which gets broadcast
all over the world). now it turns out we can call this new kind of
OCSP transactions an ISO8583, X9.59 digital signed transactions for
all financial transactions.
The actual problem is that information about whether you are entitled
to perform an operation (aka you are the actual owner of the account)
which is a only small subset of the information of interest in
performing a financial transactions. In fact, almost all merchants
from the standpoint of a financial transactions ... don't give a darn
about who you are (which is typically the information carried in a
privacy-invasive identity certificate) ... but want to know whether
they are going to get paid. Knowing that they are going to get paid
is of significant more interest than knowing who you are. Knowing who
you are can actually be considered irrelevent in a 8583/x959 financial
transaction.
If a merchant was given a choice of doing either
1) do an OCSP transaction to find out if you are still who you are
or
2) do a iso8583/x959 transaction to find out if they are going to get
paid
Which do you believe a merchant will choose ... finding out if you are
still you ... or finding out if they are going to get paid?
So with a little simplification, we have now eliminated all
transactions that involve financial matters.
So what other transactions of value do you have in mind where:
1) the information in the certificate is totally sufficient by itself
... w/o any additional recourse, for supporting the business
operation
2) there is no privacy issues when the necessary and sufficient
information by itself is broadcast all over the world.
For long detailed discussion of SLL web domain name server
certificates business:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
There have been all sorts of temporary market niches in the internet
world that doesn't necessarily actually represent a sound,
fundamental. longterm viable business proposition.
Summary of the above:
1) SSL domain name server certificates invented to address integrity
concerns/exposures with the domain name infrastructure
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
2) SSL domain name server certificates were quick&dirty fix to those
integrity issues pending fixes for the basic infrastrucutre
3) Even then the basic business premise is flawed since the
certification authorities are dependent on the domain name
infrastructure as the authoritative agency regarding who owns a domain
name
4) The irony is that the certification authority business has
proposals to improve the integrity of the domain name infrastructure
... so that they can trust the information they are certifying as to
who owns as domain name
5) Improving the integrity of the domain name infrastructure (for
purposes of the certification authority business to trust) then starts
the slippery slope invalidating the original premise for having the
certificates in the first place.
I've replayed this discussions tens if not hundreds of times .... SSL
domain name certificates (which we were somewhat involved in as per
refs in #1 above when as part of enabling this thing called electronic
commerce for doing financial transactions ... my wife and i had to
perform due diligence several of the major certification authorities)
are a quick & dirty fix to a online business integrity issue. Fixing
that online business integrity issue ... eliminates the need for the
offline certificates. Furthermore, there is some irony that the
certification authorities are pushing fixing integrity business issues
because they are also dependent on the same institutions for the
validity of the information that they are certifying.
I would, in fact, claim that the existanfe of the SSL domain name
certificate business ... supports the contention that it is a market
niche pending having the real online business ... aka in this
particular scenario the real online business exists and has for some
time ... it just is that there have been integrity issues ... and as
soon as the integrity issues for the online business processes are
fixed then the need for the SSL domain name certificate quick&dirty
fix goes away. In fact the SSL domain name certificate business is
pushing those fixes because they need it or there is then trust issues
with the information they are certifying. They can do all the
certification they want ... but if the source of the information is
bad .... what they have certified is bad.
anders.rundgren@xxxxxxxx on 12/28/2002 9:49 am wrote:
VeriSign's 500 000 Web-server certificates/year seems to contradict
the statement that there is no money in TTP-issued credentials. One
can argue about the quality of this but not the money :-)
Using OCSP, off-line "stale" credentials becomes "live" and on-line.
The alternative, having a unique credential at each resource provider
is ineffective and slows down the use of "e-services".
The real problem is that no matter what system you use, there is a
risk that the person in the other end is not the one it should be due
to credential theft, loss and to some extent due to CA errors.
/a
Invisible Ink, E-signatures slow to broadly catch on (addenda)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 01:33 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Robert E. Frank" <bobfrank@xxxxxxxx>, "Ed Gerck" <egerck@xxxxxxxx>,
epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
but as already pointed out in past investigations the banks don't
accept a random TTPs issued cert (whether using OCSP or not). They
issue relying-party-only certificates .... for privacy and liability
reasons. The certificate just contains the account number .... any
other information is privacy-invasive. So while the certificate
appears like issued from a TTP ... it is in fact, from a business
process standpoint issued by the financial institution that is
executing the transaction.
ok, have been around the relying-party-only certificate by financial
institutions numerous times before .... in much the same way have been
around the ssl domain name cert:
https://www.garlic.com/~lynn/subpubkey.html#rpo
so investigating what happens with a relying-party-only-certificate
... the financial institution registers the person's key, stores it in
their account record and issues a certificate .... also stored in the
account record.
Rather than the RPO case ... lets look at vanilla TTP w/OCSP case
(possibly 3d secure)
a single message comes with
A) the ISO8583 transaction ... 50 bytes,
B) the digital signature ... 20-40 bytes
C) the certificate ... 4kbytes to 12kbytes
the bank looks up the account record from the ISO8583 message and
checks for open to buy ... it is now ready to reply ... except it has
to
1) find the CAs public key,
2) check the trust hierarchy (which could involve large amount of
network chatter)
3) validate the certificate key
4) use the public key from the certificate to validate the financial
transaction digital signature
5) contact the OCSP (which involves more network chatter)
6) do this in under 350milliseconds (the avg. elapsed time for the
original payment gateway roundtrip)
previous refernce to the original payment gateway
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
So now .... we examine the RPO case
1) eliminated ... bank is the CA
2) eliminated ... bank is the trust hierarchy
3) bank validates their own certificate signature
4) use the public key from the certificate to validate the financial
transaction digital signature
5) eliminated ... bank account is the OCSP
now the RPO case still has the bank validating its own signature and
the humongous payload bloat caused by the certificate. X9.63 has done
a lot of work on certificate compression because of the humongous
bloated penalty that certificates place on the financial transaction
network. So, compression can use a technique of field elimination if
the relying-party already possesses the field. It is possible to show
that the relying-party for a financial transaction already possesses
all fields of interest that might be in the certificate. As a result
it is trivial to show (using X9.63) techniques that the certificate in
"C" can be reduced to zero bytes .... significantly reducing the bloat
and penalty placed on the financial network. The problem is that there
is still this transmitted certificate (even if it is only zero bytes)
that needs to have the signature verified.
so the RPO case goes to the next level of optimization. In addition to
compressing the certificate to zero bytes ... the signature on the
certificate is verified when the certificate is original issued and
deposited in the account record. Since the bank knows that only valid
information is being placed in the account record .... it is not
possible for the CA's signature on the certificate to change after it
has been deposited in the account record. So it follows, that it is
not necessary to perform subsequent checks at every transaction as to
the validity of the bank's own key.
So in the optimized version we have:
A) the ISO8583 transaction ... 50 bytes
B) the digital signature ... 20-40 bytes
C) the compressed certificate ... 0 bytes
And because validation is done at the time the information is entered
into the account record, the transaction becomes
1) read the account record from the ISO 8583 transaction
2) use the public key in the account record to validate the signature
on the ISO 8583 transaction
3) possibly do the operation in a single network round-trip of
avg. 350milliseconds.
This is very close to what is defined for ISO8583 X9.59 financial
payment standard (including the part of compressing the certificate to
zero bytes)
https://www.garlic.com/~lynn/x959.html#x959
and is also very close to what NACHA implemented for the ISO8583 debit
network trials
https://www.garlic.com/~lynn/x959.html#aadsnacha
This is also the KISS principle applied to digital signature infastructures:
https://www.garlic.com/~lynn/aadsm10.htm#hackhome Hackers Targeting Home Computers
https://www.garlic.com/~lynn/aadsm10.htm#boyd AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE
https://www.garlic.com/~lynn/aadsm11.htm#10 Federated Identity Management: Sorting out the possibilities
https://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
https://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm2.htm#mcomfort Human Nature
https://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss3 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss4 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
https://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
https://www.garlic.com/~lynn/aadsm3.htm#kiss10 KISS for PKIX. (authentication/authorization seperation)
https://www.garlic.com/~lynn/aadsm5.htm#liex509 Lie in X.BlaBla...
https://www.garlic.com/~lynn/aadsm7.htm#3dsecure 3D Secure Vulnerabilities?
https://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI
https://www.garlic.com/~lynn/aadsmail.htm#comfort AADS & X9.59 performance and algorithm key sizes
https://www.garlic.com/~lynn/aepay3.htm#gaping gaping holes in security
https://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#3dsecure4 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001i.html#51 DARPA was: Short Watson Biography
https://www.garlic.com/~lynn/2001l.html#1 Why is UNIX semi-immune to viral infection?
https://www.garlic.com/~lynn/2001l.html#3 SUNW at $8 good buy?
https://www.garlic.com/~lynn/2002b.html#22 Infiniband's impact was Re: Intel's 64-bit strategy
https://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
https://www.garlic.com/~lynn/2002b.html#59 Computer Naming Conventions
https://www.garlic.com/~lynn/2002c.html#15 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002d.html#0 VAX, M68K complex instructions (was Re: Did Intel Bite Off MoreThan It Can Chew?)
https://www.garlic.com/~lynn/2002d.html#1 OS Workloads : Interactive etc
https://www.garlic.com/~lynn/2002e.html#26 Crazy idea: has it been done?
https://www.garlic.com/~lynn/2002e.html#29 Crazy idea: has it been done?
https://www.garlic.com/~lynn/2002i.html#62 subjective Q. - what's the most secure OS?
https://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations?
https://www.garlic.com/~lynn/2002k.html#43 how to build tamper-proof unix server?
https://www.garlic.com/~lynn/2002k.html#44 how to build tamper-proof unix server?
https://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#27 Root certificate definition
https://www.garlic.com/~lynn/2002p.html#23 Cost of computing in 1958?
https://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
anders.rundgren@xxxxxxxx on 12/20/2002 11:30 am wrote:
- Using 3D Secure the bank (issuer) would check the TTP-issued cert using OCSP
- Then it would check the account
- And if it looks OK sign the transaction to the merchant
- Privacy is fairly OK unless it is a problem that the bank knows your
favorite merchants
BTW, I think that 3D, SAML et al will create a market for TTPs that
did not exist a year ago.
Invisible Ink, E-signatures slow to broadly catch on (addenda)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 03:55 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Robert E. Frank" <bobfrank@xxxxxxxx>, "Ed Gerck" <egerck@xxxxxxxx>,
epay@xxxxxxxx, "internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
somewhat total aside .... first time i ran into x.500/x.509 was at an
acm sigmod meeting. My wife and i were doing this high availability,
no single point of failure, high performance, high integrity, scalable
database work as part of the ha/cmp product:
https://www.garlic.com/~lynn/subtopic.html#hacmp
anyway, the person at the sigmod meeting was explaining x.500 as a
bunch of network gurus busily re-imventing 1960s database
technology. the work that went along with it for x.509 was (extremely
privacy invasive) identity certificates (which represented some
information supposedly contained in this x.500 1960s-era database
entries).
There was some reference that these network gurus may have been the
same people that brought us OSI. Misc. references to OSI and what went
wrong:
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
so one of the distinction often cited about the difference between ISO
and IETF (besides the difference between OSI and TCP/IP) is it is
possible for ISO to pass standards that may never, ever be implemented
(and in fact could be such that they aren't actually implementable in
any practical since). For some of the IETF standards process
description go to:
https://www.garlic.com/~lynn/rfcietff.htm
and scroll down in the main frame to the description of the standards
process and the requirement for two interoperable implementations for
standards progress.
So about the time we were doing the HA/CMP product stuff we were
also doing the hsdt project
https://www.garlic.com/~lynn/subnetwork.html#hsdt
and internet stuff
https://www.garlic.com/~lynn/internet.htm#0
and doing some stuff with high speed protocol. Part of the ISO issue
of passing standards that might not be implementable ... is that they
can also make rulings that additional standards work can't be done
unless in conforms to earlier standards activity (which might not be
actually implementable). Now ISO is somewhat schizo about this in the
area of OSI ... and things like IEEE (ISO chartered group) and LAN
standards. LAN standards effectively collapse OSI levels 1, 2, and
part of 3 into a single layer .... quite definately violating OSI. So
we were doing some stuff on HSP (high speed protocol) which would go
directly from level 4 (transport) interfacing directly to the LAN/MAC
layer. This would also violate OSI since it jumped the interface
betwen layer 3 & 4 ... and went directly to the middle of layer 3
...... which is where LAN interface sits. One of the more schizo of
the ISO organizations is US chartered X3S3.3 ... responsible for
network level 3&4 standards .... which had a strong ruling that it was
not possible to do HSP as defined .... going directly from transport
to LAN/MAC interface. Anothe example of little problems with ISO
network related standards activity.
In any case, in the HSP work .... it also looked at reliable,
high-performance transactions. HTTP (& HTTPS) uses TCP. TCP has a
minimum of 7 packets to perform reliable session/transactions. There
was some looking at VMTP which accomplishes the same thing in 5
packets. VMTP/RFC1045:
https://www.garlic.com/~lynn/rfcidx3.htm#1045
However, with a little more work, HSP came up with a reliable
transaction protocol that could be done in three packets. Slight
thread drift (which helps me remember VMTP being RFC1045) is that I
had done the RFC1044 implementation that shipped in mainframe TCP/IP
product:
https://www.garlic.com/~lynn/rfcidx3.htm#1044
which had the slight characteristic that the base implementation got
about 44kbytes/sec thruput using a full 3090 engine .... while the
enhanced 1044 implementation got 1mbyte/sec thruput (hadware media
thruput) using about 1/50th as much processing (twenty times the
thruput using 1/50th the pathlength).
So getting back to the discussion about SSL domain name
certificates. In the thread
https://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#10 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#12 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#17 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#18 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#20 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#26 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#52 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#57 Cirtificate Authorities 'CAs', how curruptable are they
as well as several other SSL domain name certificate threads:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
I make the assertion that not only does fixing the integrity of the
domain name infrastructure (on behalf of the certification
authorities) sows the seads of eliminating the SSL domain name
certificates ... but also opens the opportunity for simplifying (KISS)
the SSL protocol.
So current process is somewhat:
1) contact domain name system to get the ip-address that corresponds
to the domain URL
2) minimum 7 packet for reliable TCP for HTTP/HTTPS
3) certificate transmittal
4) ssl protocol chatter
5) hypothetical trust hiearchy network chatter to obtain necessary
signing certificates to validate certificate
6) hypothetical OSCP network chatter to check on the status of each of the signing certificates
7) hypothetical OSCP network chatter to check on the status of the domain name certificate
8) the misc. digital signature verifications with all the various public keys
9) once the SSL session has been setup the client transmits the SSL transaction request
10) the server finally gets the SSL transaction requests, does whats needed
11) replies to the SSL transaction request
12) client gets the rsponse and tears down the SSL/TCP session
Now, part of improving the domain name infrastructure integrity
... somewhat on behalf of the certification authority industry ... is
that when a domain name is registered, the entity also registers a
public key. This doesn't include a certificate ... it is just the
registration authority part of public key registration that is done at
the same time as registering the domain name (this is akin to when
somebody creates an account they supply their mother's maiden name or
some other supposed secret, it isn't necessary to have identification
... it is just that the registering entity is the one also providing
the authentication material).
So the domain name infrastructure already has the ability to serve up
all information registered with a domain name .... so the new scenario
is
1) contact domain name infrastructure and get ip-address, public key,
and whatever else may be registered (possibly including server's
preferred SSL parameters if they so desire).
2) client creates a piggybacked xtp transaction packet that has the
selected ssl parameters and the session key encrypted with the
server's public key, followed by the encrypted transaction session
information packet ... all in one transmission
3) server receives the piggybacked xtp transaction packet and unwinds
it all and performs the requested transaction
4) server responds with piggbacked xtp transaction containing the
(encrypted) response and the session tear-down
5) client response with tear-down acknowledgement
So eliminating the SSL domain name certificate not only gets rid of
the whole certificate stuff ... but eliminates huge amount of network
chatter or nattering on as one reply to the following post suggested:
https://www.garlic.com/~lynn/2002p.html#30 Sci Fi again
Basically single round trip to get the domain name information
followed by single round trip to do the SSL transaction.
ssl certs
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 07:41 PM
To: epay@xxxxxxxx
Subject: Re: ssl certs
the authoritative agency for who owns a domain name is the domain name
infrastructure. A certification authority has to check with them
regarding the validity of the application for the SSL domain name
certificate. The certification authority just certifies the
information that they have checked about with the domain name
infrastructure. I'm not saying that once they have generated a
certificate ... that the certificate can be changed.
I've saying that the domain name infrastructure has had instances of
domain name take-over. Somebody (fraudulently) takes over a domain
name and then applies to the certification authority for a SSL domain
name certificate. The certification authority just verifies all the
information .... which is then correct and then generates a
certificate based on the information that they have verified with the
authoritative agency for the information that they have certified.
So one of the proposals .... somewhat motivated by the certification
authority institutions, is to have domain name applicants register a
public key at the same time they acquire/register their domain
name. Then all further communication between the domain name owner and
the domain name infrastructure is via digitally signed messages. These
digitally signed messages don't require a certificate since the
messages are being sent to the domain name infrastructure which will
verify the digital signature with the public key on file. The
objective is to improve the integrity of the domain name
infrastructure, making domain name take-over more difficult, and
improving the trust that there would be in the validity of ssl domain
name certificates which are generated by certification authorities
... certifying information that is on record with the domain name
infrastructure.
Now the irony .... is that the registering of the public key .... on
behalf of the certification authority industry .... and using a
certificate-less process .... is part of the process that starts the
process leading to SSL domain name certificates being made redundant,
superfluous and unnecessary.
In this case, I'm not making any references to whether SSL certs (once
issued) are corruptible or not. I'm making a reference to the fact
that traditionally security is only as good as the weakest link. The
weakest link in this case is possibly not the SSL certs ...... it is
the whole backroom business process associated with the information
that the SSL certs represent, specifically the domain name
infrastructure. However, it has been integrity issues with the domain
name infrastructure that gave rise to the need for SSL certs in the
first place.
The irony is that correcting the integrity issues with the domain name
infrastructure ... on behalf of the certification authority industry
... starts down this slippery slope of making the SSL domain name
certificates redundant, superfluous and unnecessary.
refs:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
now ... as in previous discussions ... there may or may not be
additional information in the ssl domain name certificates ... but in
fact any additional information in the ssl domain name certificate is
not part of the SSL protocol and is probably viewed less than a couple
hundred times around the world. Basically, in addition to fraudulently
having done a domain name take-over .... the only other thing that is
frequently checked is that there is a D&B entry that corresponds to
the listed owner of the domain name. It is possible to trivially
generate a valid D&B entry for some business name and have that D&B
entry correspond to the listed owner for the domain name that has been
taken over. That is usually sufficient to satisfy requirements
regarding the obtaining of a valid certificate. The fact that the
business name might not be the one expected by clients ... is of
sufficiently small problem to be non-existant since effectively nobody
actually ever looks at SSL domain name certificates.
t.c.jones@xxxxxxxx on 12/20/2002 5:56 pm wrote:
Lynn: you seem to say that SSL certs are corruptable, but that doesn't
square with my experience. If the cert is correctly issued by the CA
(usually true.), then the consumer should be able to rely on the
assertion that the web page contains an offer that is really from the
merchant. What else is needed?
If you are aguing that there could be a better way, that is always
true of any system. What about the SSL cert system fails today.
(Other than an attack on the browser, which is a different story
altogether.)
..tom
ssl certs
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 10:12 PM
To: epay@xxxxxxxx
Subject: Re: ssl certs
say there is a fly by night crook ... you set up a dummy company and
get a valid D&B entry.
you do a domain name take-over ... using the dummy company name
... and then apply for a SSL domain name certificate relying on the
fact that the domain name infrastructure points to the dummy company
name.
You contract with some webhosting system with you dummy company
.... to have it all setup remotely. Nobody ever sees you. Nobody ever
looks at the content of the SSL certificate ... and the SSL protocol
only checks that the domain name in the certificate matches the domain
name name in the URL the client typed in.
The goal and the effect is nearly identical to ip-address take-over
scenario ... which is supposedly the whole reason for SSL certificates
... but only slightly more complicated. The crook has a fraudulent
webserver that everbody believes is valid ... the same as in the
ip-address scenario ... but this time the SSL certificate attests to
it also. The root problem is the same ... integrity issues in the
domain name infrastructure.
The SSL certificate stuff was a quick&dirty patch on the domain name
infrastructure with respect to ip-address take-over. However, it
effectively did absolutely nothing to handle other integrity issues in
the domain name infrastructure that can lead to the same exact fraud
as ip-address take-over. The actual difficulty in achieving this is
only moderately more than the ip-address take-over scenario
and the associated risk/rewards are well within possible fraud with
fake web servers.
The whole point of having SSL certificates was a quick and dirty patch
up for an integrity issue with ip-address take-over in the domain name
infrastructre ... however it leaves wide the domain name take-over
scenario that can result in the same exact fraud that the SSL
certificates are suppose to prevent (and the domain name take-over
exploit is only slightly more difficult and expensive that the basic
ip-address take-over scenario).
So the certificate authority industry have come up with suggestions to
improve the integrity of the domain name infrastructure .... helping
close the holes that SSL certificates are still open for ... resulting
in the same exact fraud scenario that SSL certificates are suppose to
prevent.
As previously stated .... the irony is that improving the integrity of
the domain name infrastructure .... starts to eliminate the
justification for having the SSL certificate quick & dirty fixup in
the first place aka if the domain name infrastructure has eliminated
integrity issues that make it prone to take-over of any kind
(ip-address take over or domain name take over) .... then the SSL
certificate quick & dirty fixup is no longer needed.
The whole point of having SSL certificates has been a quick & dirty
fixup to the integrity hole in the domain name infrastructure with
regard to "take-overs". It turns out that it only addressed one part
of the take-over scenarios ... not all of them. Fixing the domain name
infrastructure so the possibility for all take-overs can be eliminated
.... eliminates the need for having a SSL certificate quick & dirty
fixup (since the fundemental problem has been corrected and there is
no longer need for the SSL certificate quick & dirty fixup).
ref:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
eliminating take-over exploits in the domain name infrastructure
eliminates the major original justification for SSL domain nameq
certificates ... so we are now down to a side issue .... which was
incidental to the SSL certificate patchup for the take-over scenario
... and that is trusted key exchange. Now there are a number of
methods for doing trusted key exchange. A generic one is when one end
generates a session secret/symmetric key and encodes/encrypts it with
the public key of the other party (but there are others).
So the other part of the certification authority industry suggestion
for improving the integrity of the domain name infrastructure to
eliminate take-over situations is to have a public key registered at
the same time that the domain name infrastructure is registered. That
helps that assure the integrity of the information being
certified .... as opposed to improving the integrity of the
certificate .... it improves the integrity of the information in the
certificate.
Now, if we have a public key registered with the domain entry .... for
purpose that the domain name owner signs all email with their private
key (something that the certification authority industry is interested
in) ... then it is possible for the domain name infrastructure to
transmit that public key as part of domain name resolving ... at the
same time it transmit the resolved ip-address for the domain
name. That method of trusted real-time public key distribution then
can be used by the client for encrypting the generated
secret/symmetric secret key as described in:
https://www.garlic.com/~lynn/aepay10.htm#77
taking care of the residual justification for having SSL certificates.
t.c.jones@xxxxxxxx on 12/20/2002 8:38 pm wrote:
Allow me to use your favorit arguement. The business case here is
clear. If you steal a company's name, logo, or other IP, you will
wind up with at least a major suit from the company that owns that IP,
and perhaps more if it is shown to be fraud. You could become a
10-year room-mate of some Enron big- shots.
We should not rely on technology to solve these obvious cases of
fraud, we have lots of history dealing with fraud and should allow
those mechanisms to function.
I beleive that with SSL we have all of the technology and legal
solutions that we need today. What we need is the means to display
this information securely to the consumer and get their informed
consent to the transaction.
..tom
Invisible Ink, E-signatures slow to broadly catch on (addenda)
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/20/2002 10:44 PM
To: Einar Stefferud <Steflist@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
"Robert E. Frank" <bobfrank@xxxxxxxx>, Ed Gerck <egerck@xxxxxxxx>,
epay@xxxxxxxx, internet-payments <internet-payments@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
as discussed in the rest of this thread and the side thread
https://www.garlic.com/~lynn/aepay10.htm#78 ssl certs
https://www.garlic.com/~lynn/aepay10.htm#79 ssl certs
is that the whole SSL certificate infrastructure is already based on
domain name infrastructure .... w/o any real contractual warrant. The
domain name infrastructure is the authoritative agency for domain name
infrastructure.
You can either contact the domain name infrastructure directly w/o
contractual warranty and get the information directly
or
You can have an SSL certificate containing information where the
certification authority has contacted the domain name infrastructure
directly w/o any contractual warranty. There is the possibility that
there is a contractual warranty by the certification authority that it
has reliably contacted the domain name infrastructure with regard to
validating the information. So that is the merchant comfort
certificates ... that certification authorities will possibly warrant
that they have contacted the domain name infrastructure.
from
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
some past merchant comfort certificate threads:
https://www.garlic.com/~lynn/aadsm2.htm#mcomfort Human Nature
https://www.garlic.com/~lynn/aadsm2.htm#mcomf3 Human Nature
https://www.garlic.com/~lynn/aadsm2.htm#useire2 U.S. & Ireland use digital signature
https://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsmail.htm#comfort AADS & X9.59 performance and algorithm key sizes
https://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aepay4.htm#comcert Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert2 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert3 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert4 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert6 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert7 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert8 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert9 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert10 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert11 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert12 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert13 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert14 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert15 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert17 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay6.htm#dspki use of digital signatures and PKI
https://www.garlic.com/~lynn/2000c.html#32 Request for review of "secure" storage scheme
https://www.garlic.com/~lynn/2001c.html#62 SSL weaknesses
einar stefferud on 12/28/2002 9:50 pm wrote:
Unfortunately, from my long experience with the DNS and ICANN
travails, I must report that your trust in the contents of a DNS query
response is unwarranted. We only trust it now because monetary
transaction security considerations are not involved in DNS resolver
code.
As soon as you load the DNS with some required monetary
trustworthiness, it is subject to severe compromise.
Note that in essence you are back to trusting VERISIGN without benefit
of any contractual warranty of any kind regarding an ability to rely
on the response delivered by the DNS Resolution service.
I seriously doubt that you really want to go there!...\Stef
SSL certs & baby steps
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/21/2002 12:39 AM
To: epay@xxxxxxxx
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
"Robert E. Frank" <bobfrank@xxxxxxxx>,
Ed Gerck <egerck@xxxxxxxx>,
internet-payments <internet-payments@xxxxxxxx>
Subject: SSL certs & baby steps
so lets step back and look at it in smaller baby steps
domain name infrastructure has integrity issues that can result in
both ip-address take-over as well as domain name take-over.
ssl domain name certificates are targeted at detecting ip-address
take-over situations (by detecting that a fraudulent web server
doesn't have a certificate matching the expected domain name).
ssl domain name certicates don't address the domain name
infrastructure integrity issues associated with domain name take-over
... leaving the possibility of undetected fraudulent web servers.
so a couple items from the original electronic commerce stuff
1) my wife and I coined the term certificate manufacturing to
distinquish the deployed ssl domain name certificate quick & dirty
patch ... from a PKI
2) my wife and I wrote up some stuff about things that might be
certified as to the validatity and/or integrity of merchant sites
... which were never adopted.
so lets step back from my assertion about domain name infrastructure
server up public keys along with ip-address for domain names.
a side observation ... while domain name infrastructure may have no
warranties with respect to financial dependent transactions ... the
web and any related financial transactions are depedentent on the
domain name infrastructure correct operation in order to operate. The
ssl domain name certificates don't prevent ip-address take-over ... it
just provides a mechanism for detecting it. This possibly removes some
number of fraud motives for doing an ip-address take-over. however,
other reasons for ip-address take-over ... like denial of service
attacks can still occur, and potentially bring all such financial
transactions to a stop. So while there is no warranty with regard to
guaranteeing correct financial transactions ... there still is
significant financial exposure if such financial transactions were
prevented. Whether there are warrenties or not ... the financial
impact is nearly as bad if the domain name infrastructure doesn't have
the integrity to restand denail of service attacks is signficant (even
if one doesn't believe the domain name infrastructure will have the
warranties to back actual financial transactions).
so lets look at a little baby step that results in the domain name
infrastructure serving up a public key along with the ip-address for a
domain name.
lets say instead of registering just the public key in the domain name
infrastructure an abbreviated domain name certificate was registered
aka domain name, public key, certification authority digital signature
and a certification authority identification. Instead of serving up a
"bare" public key ... lets suppose that the domain name infrastructure
serves up such an enhanced public key. what are the differences from
the current environment.
1) current environment is dependent on the correct operation of the
domain name infrastructure to function
2) current environment uses ssl domain name certificates to detect
ip-address take over (doesn't prevent them, just detects them).
3) real-time serving of an abbreviated certificate will work correctly
when the domain name infrastructure is working correctly
4) any failure in the real-time serving of an abbreviated certificate
will result in an ip-address take over being detected.
I claim that there is no security and/or integrity difference whether
such a certified public key comes from the webserver (as in the
current implementation) or from the domain name infrastructure.
It addresses any suggestions that the fundamental holes in the domain
name infrastructure with respect to ip-address take-over may take some
time to fix and the quick & dirty fixes are with us for some time to
come.
It also has the characteristic that the domain name infrastructure can
"revoke" a certificate in real time by deleting it from the domain
name entry (and no longer serving it up). This allows effectively much
of the business characteristics of a full-blown PKI ... while not
requiring the client to implement any additional OCSP and/or CRL
complexity stuff.
the domain name infrastructure isn't at any more risk than it is today
with the SSL certificates coming from the webserver. It still is
subject to denial of service attacks because of attacks resulting in
incorrect operation. However, the availability of a valid abbreviated
certificate can detect an ip-address take-over ... and an incorrect
certificate and/or a missing certificate won't result in a valid SSL
connection by a fraudulent he.
webserver domain name infrastructure serves up public key ... just as
in my original description ... but allows that integrity issues with
respect to ip-address take-over not being fixed for some time to be
accounted for.
It also has the advantage that when operating correctly the effect of
PKI management of manufactured certificates is provided for w/o
actually involving any client implementation. It doesn't prevent any
attacks on the domain name infrastructure that result in incorrect
operation and effectively denial of service (which is exactly the same
in either SSL domain name certificate operation).
the issue is that as (or if) domain name infrastructure comes to be
trusted ... the per transaction verification of the signature on the
abbreviated certificate no longer has to be performed .... but the
data flows and the implementation operation stay the same.
Of course, this by itself does nothing to address the issue of domain
name take over integrity issues ... other than in the existing
proposal that a public key be registered when the domain name is
registered ... and that all future communication between the domain
name owner and the domain name infrastructure is digital signed (and
can be verified with the public key on file for the domain). The
public key on file can be encoded as a bare public key ... or as part
of an abbreviated certificate that is digital signed by a
certification authority. However, has detailed in the related
description for financial transactions with public key on file ... it
isn't necessary to revalidate the certification authority's signature
once the public key is reliably added to the account record.
I assert that this intermediate step retains all the integrity
characteristics of the currently deployed ssl domain name certificate
infrastructure ... with the added advantage of:
1) the effective equivalent of PKI management of manufactured
certificates is achieved by being able to eliminate/remove the
certificate from the domain name database entry (and not serve it up
... which would achieve the same thing as daily distribution of CRLs
to every possible client in the world &/or an OCSP implementation by
every client in the world)
2) the ability to create a highly optimized SSL transaction
implementation since the client can have all the necessary information
prior to initiating the webserver communication.
3) at some point when the integrity issues with the domain name
infrastructure are resolved ... and issues like denial of service
attacks are eliminated, then the public key and process data flow
stays exactly the same .... except that the bare public key can be
distributed w/o the accompanying certificate envelope.
SSL certs & baby steps (addenda)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/21/2002 09:18 AM
To: epay@xxxxxxxx
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
"Robert E. Frank" <bobfrank@xxxxxxxx>,
Ed Gerck <egerck@xxxxxxxx>,
internet-payments <internet-payments@xxxxxxxx>
Subject: SSL certs & baby steps (addenda)
there are integrity and vulnerability issues with the domain name
infrastructure
these integrity and vulnerability issues can result in various kinds
of "take-over" exploits.
the SSL domain name certificates are designed to detect ip-address
take-over exploits (not prevent them) ... and do nothing to detect
other kinds of take-over exploits.
not detecting an exploit can lead to fraudulent transactions resulting
in a financial impact
detecting an exploit will effectively degenerate to a denial of
service exploit
integrity and vulnerability issues with the domain name infrastructure
can result in various kinds of denial of service exploits
denail of service exploits of the domain name infrastructure can
result in significant financial and economic impact, possibly on par
with fraudulent transactions.
just detecting an exploit and changing it from a fraudulent
transaction exploit to denial of service exploit would still represent
a signficant financial and economic impact
it is possible to take a baby step for real-time distribution of
public keys by the domain name infrastructure .... compared to the
current infrastructure
this baby step can compensate for existing domain name infrastructure
integrity issues by having the public key signed (as opposed to
distributing naked public keys)
the current SSL domain name operation is a certificate manufacturing
infrastructure w/o the certificate management characteristics
necessary for a PKI
the baby step distribution of real time public keys can provide
effectively the characteristic of management of public keys ... by
deciding whether or not to distribute the public key
the baby step is consistent with the certification authority business
proposal for addressing domain name take-over exploits (registering
public keys with the registering of the domain name).
the baby step doesn't address the elimination of denial of service
exploits (any more than the current SSL domain name certificates do).
with the baby step there can still be denial of service attacks on the
domain name infrastructure
the baby step of adding public key distribution to the domain name
infrastructure provides public key management capability significantly
more efficiently than either distributing CRLs to every potential
client in the world and/or having clients execute OCSP transaction.
the baby step is consistent with some future real time distribution of
"naked" public keys (w/o the signing envelope) at some future time
when the integrity and vulnerability issues of the domain name
infrastructure have been sufficiently addressed. there are significant
financial and economic justification for addressing these integrity
and vulnerability issues just based on the impact of denial of service
exploits.
neither the existing ssl domain name certificate infrastructure nor
the baby step prevent ip-address take-over exploits and both just turn
an ip-address take-over exploit into a denial of service exploit.
neither the existing ssl domain name certificate infrastructure nor
the baby step prevent denial of service exploits
he baby step with real time distribution of public keys (whether
enveloped with signature for additional integrity or "naked") is
consistent with the certification authority business proposal for
improving the integrity of the domain name infrastructure by
addressing domain name take over exploits by registering public keys
in the domain name database entry.
SSL certs & baby steps
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/21/2002 09:47 AM
To: t.c.jones@xxxxxxxx
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
"Robert E. Frank" <bobfrank@xxxxxxxx>,
Ed Gerck <egerck@xxxxxxxx>, epay@xxxxxxxx,
internet-payments <internet-payments@xxxxxxxx>
Subject: Re: SSL certs & baby steps
we beleive one of the reaons that our earlier proposal for enhancemed
merchant certification didn't catch on was that electronic commerce on
the web has been extremely bi-model; something like 70 percent of the
transactions are done by some 50-60 sites and something like 90
percent of the transactions are done by 200 sites.
reputational buying decisions are very concentrated for those 90
percent of the transactions ... i.e. you have done it before, your
friends have done it, it is on the T.V. etc.
The straight forward enhanced certification process provided little or
no additional useful information for the buying decision involving
something like 90 percent of the web transactions. The URL itself was
sufficient recognition and either the current SSL (or the baby step)
precluded fraudulent transactions from ip-address take-over attempts
(but none provided any additional benefit for the myrid of denial of
service exploits). Because of the concentration of transactions the
trust has been widely established for URL for the majority of the
transactions.
The financial and economic impact for the 90 percent of transactions
on the internet is in the area of denial of service exploits (attacks
on the web services and/or attacks on the domain name
infrastructure). this is because the transactions are so concentrated
and reputational information is available because the person has made
prior purchase, they know somebody that has made purchases and/or
because of TV and other kinds of advertisement.
The place for enhanced certification process was for the remaining ten
percent of the transactions spread across the millions of remaining
web sites. The problem seemed to be the economic cost/benefit for
enhanced certificate process for the millions of web sites based on it
only was a factor in ten percent or less of all web transactions.
There was some proposal of possibly having an online BBB or some sort
of state/fed licensing board site that would give real time statistics
about complaints, resolutions, etc. This would have meaning for all
web sites ... but specifically for the web sites accounting for 90
percent of the transaction provide some additional useful information
to the consumer other than straight reputational.
the baby step proposal doesn't preclude en enhanced merchant
certification for enveloping the public key. If the domain name system
is attacked then the environment quickly degenerates to denial of
service (whether the certificate is coming from the domain name
infrastructure or from the merchant).
t.c.jones@xxxxxxxx on 12/21/2002 9:10 am wrote:
I think that you are focused on the wrong problem. Let's not obsess
about how we got here, let's look at what we have and what we want.
Do we want the NDS to overtake and subsume the existing trademark
system? I don't think so.
How about we just focus on the consumer. Let's get him the
information that he needs to make an informed buying decision. He
makes that today on brand names and logo's. I. E. on trust.
Give the consumer what they want. I am quite sure that he does not
even understand the DNS system, nor have any desire for that to become
the sole branding mechanism for the Internet.
..tom
Invisible Ink, E-signatures slow to broadly catch on (addenda)
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/21/2002 09:52 AM
To: Ed Gerck <egerck@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
"Robert E. Frank" <bobfrank@xxxxxxxx>, epay@xxxxxxxx,
internet-payments <internet-payments@xxxxxxxx>,
Einar Stefferud <Steflist@xxxxxxxx>
Subject: Re: Invisible Ink, E-signatures slow to broadly catch on (addenda)
actually i think we are in violant agreement ... possibly as some of my
later posts regarding ssl certs and baby steps may show.
egerck@xxxxxxxx on 12/21/2002 9:44 am wrote:
This is not quite correct. The DN in a X.509/PKI cert had nothing to
do with the DNS. It was the lack of foresight of some people that has
made PKIX vulnerable to yet another problem -- the DNS.
Also, may I recall that there is no "SSL certificate
infrastructure". What we have is a PK wanna-be I. And, SSL is broken
anyway. It does not prevent server spoofing, its MSIE implementation
allows easy MITM attacks that can read all traffic in the clear, and
here are additional 24 problems (dure to PKI) that I have documented
since 1997, which paper was downloaded more than a million times and
presented at the Balck Hat Conference in '99. You can search in google
for a copy near you, using the query "Overview of Certification
Systems Gerck"
And, PKI certs are simply too big for wireless and also for everyday
use -- this message would probably more than double in size if signed.
Cheers,
Ed Gerck
x959 Postings and Posting Index,
next, previous
- home