Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next, previous - home
- DNSSEC (RE: Software for PKI)
- 3D Secure Vulnerabilities?
- 3D Secure Vulnerabilities?
- DNSSEC (RE: Software for PKI)
- Seeking Privacy Online, Even as Security Tightens
- Software for PKI
- Software for PKI
- Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
- Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
- Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
- A PKI Question: PKCS11-> PKCS12
- A PKI Question: PKCS11-> PKCS12
- A PKI Question: PKCS11-> PKCS12
- A PKI Question: PKCS11-> PKCS12
- CFP: PKI research workshop
- CFP: PKI research workshop
- CFP: PKI research workshop
- CFP: PKI research workshop
- CFP: PKI research workshop
- CFP: PKI research workshop
- CFP: PKI research workshop
- CFP: PKI research workshop
- CFP: PKI research workshop
- CFP: PKI research workshop
- CFP: PKI research workshop
- CFP: PKI research workshop
- Small/Secure Payment Business Models
DNSSEC (RE: Software for PKI)
From: Lynn Wheeler
Date: 11/09/2001 04:55 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, lynn.wheeler@xxxxxxxx
Subject: Re: DNSSEC (RE: Software for PKI)
i managed to fat finger some number of the URLs in the previous note ...
they've been corrected in the version at:
https://www.garlic.com/~lynn/aadsm8.htm#softpki19
3D Secure Vulnerabilities?
From: Lynn Wheeler
Date: 11/09/2001 06:26 PM
To: "Richard D. Brown" <rdbrown@xxxxxxxx>
cc: internet-payments@xxxxxxxx
Subject: RE: 3D Secure Vulnerabilities?
even more so ... between the draft and the published version ... there
was significant "cleaning" of the issues around public-key,
private-key, digital-signatures, certificates, etc. Drafts right up to
the final document included keys, signatures and certificates in
various portions of the ASN.1 specification ... all of that got
clieaned.
the x9.59 doesn't have integration constraints per se ...
the requirements given to the X9A10 standard working group for X9.59
was that it be applicable to all account-based payments and preserve
the integrity of the financial infrastructure. There was a great deal
of effort that went into the standard in attempt to make if applicable
to all account-base payments and preserving the integrity of the
financial infrastructure.
rdbrown@xxxxxxxx on 11/9/2001 wrote:
Actually, having reviewed the draft document, it's true that the standard
does not mandate any specific algorithm. However, there are so many
references in the normative text to 'public-key', 'private-key',
'signature'... that it certainly implies the use of an asymmetric
crypto-system, and more specifically, use of a public-key digital signature.
But I can see, where you're coming from... ;)
Certainly, it would be possible to leverage X9.59 payment objects in a TVC
context. However, X9.59 has integration constraints (i.e. adapting current
ISO8583 infrastructures) that would defeat the main purpose/objective of
TVC.
-RDB-
3D Secure Vulnerabilities?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/10/2001 01:37 PM
To: "Richard D. Brown" <rdbrown@xxxxxxxx>
cc: internet-payments@xxxxxxxx
Subject: RE: 3D Secure Vulnerabilities?
somewhat as an aside .... while there was a lot of work done on
mapping/integration of X9.59 into payment cards .... debit/credit,
x9.15/iso8583, etc .... providing seemless, end-to-end, authenticated,
secure transactions ..... "all account-based transactions"; preserving
the integrity of the financial infrastructure .... also involved
looking at many of the financial transaction infrastructures ...
debit
credit
ATM
ACH
"e-check"
fedwire
swift
somewhat similar being able to help author the NACHA pilot
specification for internet debit transactions:
https://www.garlic.com/~lynn/x959.html#aads
we also talked to fedwire and swift and was able to help author swift
proposal.
the x9a10 group took its charter seriously for a standard that could
be applicable to all account-based transactions and preserve the
integrity of the financial infrastructure.
with regard to using FIPS186-2, EC/DSA federal standard for
authentication ... there was a minor characteristic noted that such a
digital signature could also help in identify replay-attacks &
duplicate transactions. A FIPS186-2 federal standard for
authentication effectively creates a unique signature for every
signing .... even if the same exact data is signed multiple
times. Different transactions that otherwsie look the same will have
different authentication signatures. Duplicate transactions will have
the same exact signature.
one of the side issues of doing a standard is that it isn't vendor
proprietary. that obviously can have a lot of advantages to customers
but standards can have both their upside & downside. vendor
exclusivity can have the characteristic that there is market entity
with extra justification to champion and fund deployment. ... which i
guess could be considered the opposite of open-systems and
interoperability.
DNSSEC (RE: Software for PKI)
From: Lynn Wheeler
Date: 11/11/2001 11:58 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: DNSSEC (RE: Software for PKI)
and from the archives on a long ago, far away project ... price has
come down some ....
Date: 1 July 1985, 08:17:15 MDT
To: WHEELER
Lynn,
re: your questions about the public key encryption unit
The Racal-Milgo Datacryptor III uses a AMD DES chip plus some
proprietary logic for exchanging master keys using a public key
approach. The master keys are then used to encrypt the working keys
which are actually used for data encryption. I have run the off the
shelf units at 128kb full duplex through the V.35 interfaces contained
in the unit. They cost about $3,200 each, single unit price.
I have to emphasize they are link level encryptors (e.g. level 1)
rather than level 2 (e.g. only the data encrypted with addressing in
the clear). They won't do you much good for "session" or "file"
encryption. The public key synopsis goes something like this -
1. At install time, two 60 digit prime numbers are acquired and retained in
storage. The 'seeds' are developed by a combination of an operator
pressing a button to sample a clock source along with internal logic.
2. When a operator wants to move a master key online, he asks the remote end
for a one-time E key (56 bits plus 8 parity bits).
3. The remote end uses the two 60 digit prime numbers (with their 120 digit
product) to create a E key and a D key. They are "mathematically related
to the prime numbers and to each other" to quote the Racal documentation.
4. The E key can't be used for decryption and the D key can only decrypt
what has been encrypted with the E key.
5. The remote end retains the D key and sends the E key to the 'requestor'.
6. The local end generates a new master key, encrypts it with the E key he
just received, and sends it to the remote end.
7. The remote end decrypts the transfer with the D key he retained, they
exchange a test message for verification, and exchange a new working key.
8. The E/D pair of keys are not reused. Each exchange of a master key causes
a new pair to be created. The E/D pair never leave the boxes, and can't
be read out or displayed. It takes about 8 seconds for the hardware to
do the decryption of the received master key using the D key previously
retained.
anders.rundgren@xxxxxxxx on 11/9/2001 12:19 pm wrote
These DNSSEC servers will not be practical until HW-crypto
support is down in the $100 region. This may take another
5 years or so. It is driven by the B2B market that needs such
servers as well.
Seeking Privacy Online, Even as Security Tightens
From: Lynn Wheeler
Date: 11/12/2001 10:31 PM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: cryptography@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Seeking Privacy Online, Even as Security Tightens
... blast from the past.
To: security@xxxxxxxx
Subject: Re: The Electronic Communications Privacy Act
Date: Wed, 13 May 87 15:07:03 EDT
From: Henry Mensch <henry@xxxxxxxx>
This is what the MIT community (in general) was told about how this
law affects our work. It sounds to me like the ECPA is talking about
BITNET also. (Of course, the Act has no clue about "ownership" of
data--they don't ever seem to define it).
This is a copy of a letter published in Tech Talk. Anyone who
did not read that memo should look read it. Be sure to note that
operators of electronic communication systems now have legal
responsibilities for the privacy of data.
[Thanks also to Joe Harrington who forwarded a copy. _H]
MEMORANDUM
To: The MIT Community
From: James D.Bruce, Vice President for Information Systems
Re: The Electronic Communications Privacy Act
The Electronic Communications Privacy Act of 1986 was enacted by
the United States Congress in October of last year to protect the
privacy of users of wire and electronic communications.
Legal counsel has advised MIT that its computer network and the
files stored on its computers are covered by the law's provisions.
Specifically, individuals who access electronic files without
appropriate authorization could find themselves subject to criminal
penalties under this new law.
At this time, we can only make broad generalizations about the
impact of the Act on MIT's computing environment. Its actual scope
will develop as federal actions are brought against individuals who
are charged with inappropriate access to electronic mail and other
electronic files.
It is clear, however, that under the Act, an individual who,
without authorization, accesses an electronic mail queue is liable and
may be subject to a fine of $5,000 and up to six months in prison, if
charged and convicted. Penalties are higher if the objective is
malicious destruction or damage of information, or private gain.
The law also bars unauthorized disclosure of information within an
electronic mail system by the provider of the service. This bars MIT
(and other providers) from disclosing information from an individual's
electronic data files without authorization from the individual.
MIT students and staff should be aware that it is against
Institute policy and federal law to access the private files of others
without authorization. MIT employees should also note that they are
personally liable under the Act if they exceed their authorization to
access electronic files.
Software for PKI
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/16/2001 04:35 PM
To: "Housley, Russ" <rhousley@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: RE: Software for PKI
it was a multi part piece of logic
1) part one ... early X.509 Identify certificate work for offline
credentials has morphed into several other forms
2) ... identity is useful for more than a single relying party
3) ... eliminating identity ... somewhat restricts the domain of offline
credentials.
4) one of the morphs was into online relying-party-only credentials
5) it was possible to show that in the case of relying-party-only
credentials, the relying-party-only certificates were unnecessary,
superfluous, and redundant.
As before the nominal X.509 identify offline certificates could
involve into other types of offline information binding
credentials. However, many of the X.509 offline credential morphs for
the online world could be shown that such credential was unnecessary,
redundant and superfluous (when the online original of the
information was being accessed).
In the case of a relying-party-only scenerio that was accessing the online,
real time account information ... that contained the original of the
relying-party-only certificate .... it was possible to show either
a) reduction of the appended relying-party-only certificate to zero bytes
... since the receiving relying party already had a copy of all the
information in the relying-party-only certificate
b) eliminating the appended relying-party-only certificate ... since the
receiving relying party already had the original of the relying-party-only
certifciate.
replay of this same discussion in this newsgroup from august of last year
https://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability
https://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
general thread on offline stale credential vis-a-vis online, real-time
information:
https://www.garlic.com/~lynn/aadsm2.htm#techno digital signatures, technology experiments, and service operations
https://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
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#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/aadsm4.htm#9 Thin PKI won - You lost
https://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#liex509 Lie in X.BlaBla...
https://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die
https://www.garlic.com/~lynn/aadsm5.htm#spki Simple PKI
https://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
https://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
https://www.garlic.com/~lynn/aadsm7.htm#rhose10 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose11 when a fraud is a sale, Re:Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
https://www.garlic.com/~lynn/aadsmore.htm#pressign President Clinton digital signing
https://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
https://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
https://www.garlic.com/~lynn/aepay3.htm#openclose open CADS and closed AADS
https://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate
https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 updates for (AADS) Relying-Party Certification Business Practices
https://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
https://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000.html#40 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000b.html#40 general questions on SSL certificates
https://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format standard
https://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
https://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#0 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
rhousley@xxxxxxxx on 11/12/2001 6:20 AM wrote:
Lynn:
Good grief. You are a smart guy. Do you say these things just to provoke
reaction?
There is nothing in X.509 or PKIX that warrants such statements.
The whole point of a public key certificate is to bind a public key to an
identity. The form of the subject identity can be application
specific. For example, to support S/MIME, the certificate binds an
electronic mail address to the public key. To support a anonymous payment
protocol, the certificate would likely bind the public key to an identifier
of the financial institution and an account number, where only the
financial institution need know the identity of the account owner. This is
clearly the opposite end of the spectrum from QC defined in RFC 3039.
Do not condemn the public key certificate because one application makes use
of a different form of identity than another application.
Russ
Software for PKI
From: Lynn Wheeler
Date: 11/16/2001 04:50 PM
To: "Housley, Russ" <rhousley@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: RE: Software for PKI
... also, with respect to the other direction this thread has taken ....
some of the business justification issues may be when force-fitting
offline, non-identity credentials manufactured at some time in the past
.... into environment that is directly accessing the online, real-time,
non-stale, superset of the credential (the easily obvious is the financial
institution case, that given only the account number ... the operation
references the account record which contains the real-time, online,
non-stale, superset of the credential).
rhousley@xxxxxxxx on 11/12/2001 6:20 AM wrote:
Lynn:
Good grief. You are a smart guy. Do you say these things just to provoke
reaction?
There is nothing in X.509 or PKIX that warrants such statements.
The whole point of a public key certificate is to bind a public key to an
identity. The form of the subject identity can be application
specific. For example, to support S/MIME, the certificate binds an
electronic mail address to the public key. To support a anonymous payment
protocol, the certificate would likely bind the public key to an identifier
of the financial institution and an account number, where only the
financial institution need know the identity of the account owner. This is
clearly the opposite end of the spectrum from QC defined in RFC 3039.
Do not condemn the public key certificate because one application makes use
of a different form of identity than another application.
Russ
Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/26/2001 01:45 PM
To: <pasward@xxxxxxxx>
cc: dcsb@xxxxxxxx, Kent Borg <kentborg@xxxxxxxx>,
"R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
there are two issues in an ATM:
1) the electronic security and
2) the physical security of cash
... aka ATMs besides doing ATM transactions ... also contain physical
cash ... potentially on the order of thousand or more $20 bills.
the electronic security of a PC is somewhat questionable in the near
term ... although it has the characteristic that some of the things
that can be done ... can be done by the PC owner (i.e. the owner of
the PC has some control over how little or how much security they are
willing to employ).
for PC-banking ... there has been some work in the EU for the finread
standard ... basically a hardware token along with a "secure"
reader. The finread "secure" reader is somewhat like the atm/debit
terminal at check-out counters .... it is spec'ed to have a particular
kind of "security module", tamper evident standards, its own keyboard,
and its own display. The process is that the customer uses their
hardware token (in the case of current debit/credit a plastic card
with magstripe), enters the PIN securely, the terminal securely
displays the amount of the transactions, and the customer confirms the
transactions.
The finread standard is similar to the check-out counter ATM/debit
terminal ... but for consumer attachment to PCs ... and its for
chip-cards. It has its own separate pin entry, and can have its own
separate display. Virus's on the PC can't generate fraudulent
transactions when you aren't looking ... it requires your hardware
token and physical person interaction with the terminal/reader for
potenailly every transaction of specific kind.
random finread refs:
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
https://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market.
the other part is enabling secure debit/ATM transactions in the open
network environment. NACHA has done trials for secure transactions in
the open network environment (the other part of the ATM/debit-POS is
that the transactions flow over a closed network),
random refs:
https://www.garlic.com/~lynn/x959.html#aads
https://www.garlic.com/~lynn/aadsm6.htm#echeck Electronic Checks
https://www.garlic.com/~lynn/aadsm6.htm#aadsatm (certificate-less) digital signatures can secure ATM card payments on the internet
https://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
https://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
https://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm8.htm#3dvulner3 3D Secure Vulnerabilities?
https://www.garlic.com/~lynn/aadsm9.htm#3dvulner5 3D Secure Vulnerabilities?
https://www.garlic.com/~lynn/aadsmore.htm#nacha NACHA digital signature pilot
https://www.garlic.com/~lynn/aadsmore.htm#debitfraud Debit card fraud in Canada
https://www.garlic.com/~lynn/aepay6.htm#ecomich call for new measures: ICH would be glad to help
https://www.garlic.com/~lynn/aepay6.htm#userauth MS masters NC mind-set (authentication is the key)
https://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nacha Nacha reports mentions X9.59 payment protocol
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay7.htm#nachaxml Unified Modeling Language (UML) for NACHA Business Models & XML Project
https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 updates for (AADS) Relying-Party Certification Business Practices
https://www.garlic.com/~lynn/ansiepay.htm#aadsach NACHA to Test ATM Card Payments for Consumer Internet Purchases
https://www.garlic.com/~lynn/ansiepay.htm#atmdebit NACHA AADS ATM debit ... from tomorrow's american banker
https://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
https://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#36 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#37 Credit Card # encryption
https://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
https://www.garlic.com/~lynn/2001l.html#51 Security standards for banks and other institution
pasward@xxxxxxxx on 11/26/2001 8:10 AM wrote:
Perhaps I should clarify. The issue is not me per se, but the general
problem of securing a PC to the level of an ATM. Otherwise, banking
on it is unattractive. Banks exist on goodwill, and a PC-banking
scheme that destroys that goodwill through insecurity is hardly a good
thing.
Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/26/2001 02:44 PM
To: Kent Borg <kentborg@xxxxxxxx>
cc: dcsb@xxxxxxxx, pasward@xxxxxxxx, "R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
there are a number of integrated versions where a hardware token has
an "on-device" numeric keypad or even some sort of "on-device"
biometric sensor like a fingerprint reader. that can slightly cut the
total cost if there is always a one-to-one relationship between
hardware token and secure reader ..... but in an environment where
there is a large ratio of cards-to-readers ... then it is more
expensive.
one of the issues is that the original target market for "smartcards"
is now occupied by PDAs and cellphones (i.e. portable computing
devices .... but with advances in technology so that the input/output
is now integrated). reduced function chip-cards could be used as
secure hardware tokens for authentication ... w/o carrying the
overhead and costs of much of the current generation of smartcards
... i.e. the AADS chip strawman at:
https://www.garlic.com/~lynn/x959.html#aads
a secure PDA or cellphone should be a lot easier to do than getting a
full-blown secure PC (where there could be an embedded chip that
represents the secure hardware token functionality).
kentborg@xxxxxxxx on 11/26/2001 02:27 pm wrote:
Interesting.
Sounds like my suggestion of a mini combo IBM cryto card and a user
authentication input device--but split in two, where the user has to
trust the integrity of the keypad. But it would be a lot cheaper
per consumer, which means it might actually happen.
-kb, the Kent who doesn't like logging into his basement server from a
computer he doesn't physically control, such as those at an internet
cafe.
Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
Refed: **, - **, - **
From: Lynn Wheeler
Date: 11/26/2001 03:26 PM
To: <pasward@xxxxxxxx>
cc: dcsb@xxxxxxxx, Kent Borg <kentborg@xxxxxxxx>,
"R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
my only claim is that it would be a whole lot easier to fix cell-phone
software to make cell-phones secure (for some measure of security) ...
than it would be to change all the PC software to make PCs secure (to
the same measure of security). also, adding a separate hardware
embedded chip that was specific for authentication wouldn't be
difficult.
however, all security is relative .... frequently cost/benefit
trade-off (aka translate "easier" in previous paragraph into "dollars"
... the cost difference between cellphones and PC is likely to be
several orders of magnitude) .... also some from the security
proportional to risk thread:
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???
at 11/26/2001 3:10 PM wrote:
It is my understanding that the by-design security of various
cellphones is such that they are relatively trivial to break into.
There has been some discussion of this on comp.risks.
A PKI Question: PKCS11-> PKCS12
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/27/2001 05:45 PM
To: Hal Lockhart <hal.lockhart@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, "'RAGHAVENDRAN H. (SSG) - CTD, Chennai.'"
<raghavh@xxxxxxxx>
Subject: RE: A PKI Question: PKCS11-> PKCS12
PKI key operations can be put into two categories .... authentication
(digital signatures) and secrecy/privacy (encryption).
It is reasonable to have a hardware token with a private key that was
generated in the chip and never leaves the chip for use in
authentication applications .... i.e. digital signatures for reliably
authenticating an entity.
Most key escrow and business continuity issues involve privacy,
secrecy, encryption and recovery of information; aka essential
corporate assets protected with encryption could be lost if the access
to the encryption key only existed in a single chip and that chip
malfunctioned (a continuous availability issue with regard to
no-single-point-of-failure and redundancy ... for high value assets,
frequently not even simple duplicates, but even higher levels of
redundancy and availability).
While it is possible that the same kind of chips and similar public
key technology may be used in the two cases, the actual business
processes (authentication and secrecy/privacy) have different
requirements and design points.
It is possible to define chips/crypto for use in authentication-only
business processes to have requirements that the private key be unique
to a hardware token and never divulged. At the same time, it is also
possible for essentially identical chips/crypto for use in
secrecy/privacy business processes to have requirements that there be
no single point of failure (even down to the hardware token containing
a private key) which involving critical business assets. To meet
business continuity and availability requirments it is possible that
private keys involve in encryption for secrecy/privacy issues be
replicated via means like key escrow.
The business requirments are different for the two different
scenarios, even if the technology is otherwise identical.
on 11/27/2001 11:59 AM wrote:
Generating a secret on a smartcard and having it never leave the card
is a major security feature to many people. For example, I believe it
is mandated by Identrus for financial transactions. It is certainly a
major motive for using smartcards, since it insures that all copies of
the key are protected, not just one of them. It also insures that an
attacker can not read out the key and use it in some environment where
the card is not present.
On the other hand, many people believe in the benefits of key backup,
particularly in a corporate environment, where the assets being
protected belong to the organization not the individual. Also some
folks believe that a central facility can do a better job of
generating unguessable keys than a smartcard with limited processing
power.
There is never any reason to protect certificates, since they are
signed and intended to be public knowledge. They tend to take a lot of
precious space on a smartcard. But, given the lack of a universally
deployed directory infrastructure, it is convenient to have them "with
you".
However, trusted root keys (which may be held in a self signed
certificate for processing convenience) must be protected from
modification.
Hal
A PKI Question: PKCS11-> PKCS12
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/27/2001 09:10 PM
To: Richard Culshaw <RCulshaw@xxxxxxxx.au>
cc: <ietf-pkix@xxxxxxxx>,
"'RAGHAVENDRAN H. (SSG) - CTD, Chennai.'" <raghavh@xxxxxxxx>
Subject: RE: A PKI Question: PKCS11-> PKCS12
note that bank vaults and armored trucks have things put into and
taken out of them all the time ... and they are still considered
secure.
in the scenario of digital signature & public key for authentication,
it is possible that there is a business requirement for
non-divulging/exporting the private key.
however, in the scenario of hardware tokens protecting private key(s)
involved in secrecy/privacy encryption there can be significant
reasons for having private key replication ... especially if very
valuable corporate assets are involved.
hardware tokens can be secure .... whether they implement private key
exporting or not. In the business process of authentication there can
be higher confidence that with a non-export private key policy there
is improved non-repudiation. However, that shouldn't negate the fact
that similar secure hardware tokens can't be used to protect private
keys that have been replicated for various business purposes (that
don't involve things like non-repudiation).
There can be some confusion when identical technology is being used
for totally different and distinct business purposes .... where the
associated business requirements for the different business processes
can place different requirements on the technology.
on 11/27/2001 4:27 PM wrote:
HI there,
I have tested numerous different smart cards/USB tokens and software
combinations and have not seen one that offers a p12 export facility. The
Purpose of having a smart card is to be able to securely store the Private
key, if it can be exported from the smart card/token then it isn't really
secure.
Richard Culshaw
A PKI Question: PKCS11-> PKCS12
From: Lynn Wheeler
Date: 11/28/2001 10:55 AM
To: Hal Lockhart <hal.lockhart@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx,
"'RAGHAVENDRAN H. (SSG) - CTD, Chennai.'" <raghavh@xxxxxxxx>
Subject: RE: A PKI Question: PKCS11-> PKCS12
the categories were respect to business processes and business requirements
.... there has been recent thread in this mailing list somewhat touching on
the fact that technology implementations and business requirements might
not necessarily match up very well ... as well as some number of people
working with PKI understanding that there are fundamentally different
business processes and business requirements using the same technology.
Note that it is somewhat mute issue with regard to software PKI
implementations .... the possible business requirements don't see a lot of
differences until you get to hardware token and then there can be a real
issue of whether or not the private key is ever divulged. Also from a
business continuity stand-point .... there can be short-cuts in many of the
secrecy protocols involving date-in-flight (including email) ... it is
long-term encryption involving data-at-rest where non-replicated keys can
become serious business risk (and single-points-of-failure). Nominally
email is immediately decoded and possibly NACK'ed if there is a problem
(like my private key is broken), aka email is much more of a data-in-flight
business operation.
Not having replicated keys for protected, encrypted data-at-rest business
assets is analogous to not taking backups and having business continuity
plans. Several years ago, there was some study that of the businesses that
didn't have disk backups of business data when there was hard disk failure
... half filed for bankruptcy within the first 30 days (after the disk
failure). Loss of hardware-token/key for critical business assets protected
by encryption ... effectively can represent equivalent loss of the data.
With regard to SLL merchant authentication with merchant server domain name
certificates for SSL ... the CA signing serves most of the authentication
function with the merchant key serving the encryption function (for key
exchange) .... with somewhat the caveat that if the merchant can decrypt
the key exchange it also has an implied authentication Any other activity
with regard to merchant key is somewhat protocol chatter ... i.e.
1) if the merchant certificate validates (with the CA key) and the domain
name matches there is first level of authentication (CA key is an
authentication business process)
2) if the merchant can decrypt the key-exchange from the client (and
correctly respond with encrypted message) .... then there is pretty good
proof that the merchant is the corresponding entity from #1.(merchant key
is a encryption business process).
at 11/28/2001 9:37 am wrote:
> PKI key operations can be put into two categories .... authentication
> (digital signatures) and secrecy/privacy (encryption).
I know this is the orthodox theory, but in practice IETF PKI protocols and
applications make this difficult or impossible. Generally one key is used
for Authentication and Key exchange, effectively encryption.
That's how TLS and IKE work. Just try using two keys with Outlook.
Hal
A PKI Question: PKCS11-> PKCS12
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/28/2001 02:35 PM
To: Eric Norman <ejnorman@xxxxxxxx>
cc: "Ietf-Pkix (E-mail)" <ietf-pkix@xxxxxxxx>,
"'RAGHAVENDRAN H. (SSG) - CTD, Chennai.'" <raghavh@xxxxxxxx>,
Richard Culshaw <RCulshaw@xxxxxxxx.au>
Subject: RE: A PKI Question: PKCS11-> PKCS12
try bank debit card infrastructure. there is a hardware token/box that
is protecting the bank's "key" which then all of the individual
account keys are encoded with. for a large bank, there could be dozens
of these hardware units to handle the debit transaction load. In
addition, there are copies of the keys likely escrowed in some other
institution's safe deposit box (aka keeping the escrow in the same
institution's safe deposit boxes could represent a collusion risk).
It is slightly analogous to a CA model (in that the bank's key is
encoding the account key as opposed to signing the account key)
... except then all transactions are coming back to the
account-authority (i.e. the account-authority and the relying party
are the same), and the hardware box gets fed the encoded account
information, the transaction ... and validates the transaction.
on 11/28/2001 11:19 AM wrote:
It seems to me that if a corporation has designed its business
practices such that valuable corporate assets pass through a
single point of encryption (aka single point of failure), then
it would be wise for that corporation to review and adjust
its business practices.
Eric Norman
"I may be just a butterfly,
but watch out if I flap my wings"
CFP: PKI research workshop
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/26/2001 01:03 PM
To: Ray Dillinger <bear@xxxxxxxx>
cc: Carl Ellison <cme@xxxxxxxx>, cryptography@xxxxxxxx,
SPKI Mailing List <spki@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
note that the certificate-based PKI is an offline model .... it is the
credit card model pre-1970. the certificate-based PKI tends to bear a
lot of other resumblance to pre-1970 offline credit-card model
.... the CRLs invention is very similar to the paper booklets that
were mailed out to merchants every month of invalid credit card
numbers (the credit-card industry however had a significant advantage
having a very strong relying-party registration function .... so that
there was high probability of relying-parties getting the paper
booklets of invalid numbers).
in the '70s, the credit card industry switched from an offline
infrastructures (aka similar to the certificate-based PKIs which were
effectively developed to address the offline email infrastructure of
the early 1980s) to an online infrastructure ... where every
transaction was executed online. A certificate-based PKI for credit
cards would be like regressing 30 years to the offline infrastructure
(although using more convoluted and complex technology). The issue is
why would the payment card industry want to regress 30 years to an
offline model with certificate-based PKI?
The financial industry has passed an online payment definition that
does use digital signature technology w/o all the complexity and
short-comings of a certificate-based PKI (that would set-back/regress
the infrastructure 30+ years to the offline model) .... which is
X9.59.
Baiscally X9.59 defines a retail payment object that is valid for ALL
electronic online financial transactions (internet, non-internet,
point-of-sale, debit, credit, ACH, etc) which basically requires a
digital signature and does not require a certificate-based PKI. The
simplest analogy is that digital signature technology upgrades the
PIN-based infrastructure found in current debit transactions and
expands it to all electronic financial transactions.
There have been some financial pilots using certificate-based PKI
operations .... but in all cases it is relatively trivial to show that
the certificate is redundant, superfluous and extraneous in an online
world. The certificates were effectively relying-party-only
certificates (basically containing an account number and a public key)
.... in part to meet liability and privacy requirements. Since only an
account number was used and the transactions &/or other operations
were all online ... they all referenced the account in order to
execute the requested operation. It is trivial to show that given
online operation executioin (including things like "logging in" for
vaious kinds of things related to online banking and/or other
financial or securities industry transactions) .... that is
superfluous to have the certificate.
The certificate makes sense in an offline environment where there is
no prior business relationship between the entities. Given online
situations involving parties with prior relationships, certificates
make no sense.
misc. x9.59 references:
https://www.garlic.com/~lynn/x959.html#x959
misc certificate-less digital signature references (including pointers
to the NACHA/debit network implementation ... and a private key
hardware token description allowing the same private/public key to be
used in an arbritrary large number of different & public operations):
https://www.garlic.com/~lynn/x959.html#aads
random client digital signature authentication refs:
https://www.garlic.com/~lynn/subpubkey.html#radius
misc. discussion of certificate-based SSL domain name operation:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
ray dillinger on 12/26/2001 12:03 pm wrote:
Yep. So far, that's true. Financial stuff is the only killer app
in sight for a PKI, and the financial services sector is conservative
and heavily regulated. There is a substantial barrier to entry: just
try to imagine running off a few thousand PKI-backed credit cards and
going into business competing against mastercard/visa/amex. Vendor
acceptance is slow and the regulatory hurdles are high.
........
Odds are, however, that each and every one of them is going to want
their own PKI -- where P stands for Private, or Proprietary, rather
than Public. A Public Key Infrastructure happens when the chaotic
situation which that brings about gets consolidated and standardized,
so don't look for that for at least a decade. Basically we have no
chance of getting a Public Key Infrastructure in place right now
because we don't have enough different Private Key Infrastructures
in place for it to have started to hurt yet. People won't go for
the PKI until they are in some kind of pain that it relieves. And
if financial services businesses are involved, they will do it in
such a way that no PKI vendor ever makes a profit they could possibly
have made themselves. Look for them to be buying regulations that say
PKI is part of financial services and can only be provided by licensed
financial services corporations sometime in the next few years.
Like I said, don't get too discouraged -- these things happen slowly
and it's very much a matter of stages of development. People don't
do things until the pain of not doing them gets worse than the pain
of doing them. Public Key comes about when Private Keys have been
common for several years and their multiplicity causes pain. That
in itself will take several years after the Private Key structures
are fully adopted. The Private Key structures get adopted several
years after the profit margins, split between consumers, vendors, and
financial institutions, each overcome the pain of changing infrastructure.
That will take several years after the initial offering. The initial
offerings are happening now in very restricted markets, but don't
look for it to happen in domestic consumer markets until the results
of the restricted-market offerings are several years old and the
technology involved hasn't changed AT ALL for several years. They
are looking for a technology that's been in use long enough to
establish a baseline and get results that look stable and repeatable.
That's when financial services companies will begin to take them
seriously enough to consider that the pain of deploying new
infrastructure may overcome the painof absorbing losses due to
fraud.
These are just network effects: PKI will trickle through at the end
as surely as water runs downhill, because it's a better solution.
It's just going to take a decade or two, or maybe four or five
decades if there's a substantial monopoly somewhere in the industry.
Bear
CFP: PKI research workshop
From: Lynn Wheeler
Date: 12/26/2001 01:35 PM
To: Matt Crawford <crawdad@xxxxxxxx>
cc: cryptography@xxxxxxxx,
SPKI Mailing List <spki@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
possibly not the ATM you were thinking of .... certificate-less
digital signature authentication by NACHA/ATM/debit networks
https://www.garlic.com/~lynn/x959.html#aads
specific web page:
https://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm
financial industry standard for digital signature authenticated
electronic payment transactions for all payments (x9.59):
https://www.garlic.com/~lynn/x959.html#x959
misc discussions regarding privacy and certificate-less digital
signature authentication
https://www.garlic.com/~lynn/subpubkey.html#privacy
matt crawford on 12/26/2001 8:20 am wrote:
As I never tire of saying, "PKI is the ATM of security."
Meaning that has a certain niche relevance, but is claimed by
proponents to be the answer to every need, and is the current magic
word for shaking the money tree.
CFP: PKI research workshop
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/26/2001 02:36 PM
To: Ray Dillinger <bear@xxxxxxxx>
cc: Matt Crawford <crawdad@xxxxxxxx>, cryptography@xxxxxxxx,
SPKI Mailing List <spki@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
again, why would the financial industry be interested in regressing
(at least) 30 years to a certificate-based offline model?
they do authentication of transactions that they also need to do
authorization for .... in a model that has prior business
relationship between the parties. certificate-based PKI were targeted
at offline email genre of the early '80s and analogous to the offline
credit-card model pre-70s.
in addition to the x9.59 for all electronic payment transactions
... it is possible to extend online authentication where the
institution possibly isn't also responsible for the authorization
(and/or access privileges).... things like FAST projects in FSTC:
http://www.fstc.org/projects/fastaggregation.cfm
ray dillinger on 12/26/2001 12:31 pm wrote:
In fact, that may be exactly it. PKI, as espoused by vendors,
once established, will become an indispensable monopoly, like
AT&T before the breakup. Investors love the fantasy of buying
a kajillion shares for cheap today and then having them be
shares in an indispensable monopoly next year, so they are
inclined to believe.
The problem is that none of the vendors are offering anything
that someone who has significant volume (like a financial-services
company might) cannot provide for themselves. The FS companies
can easily wait to adopt, because the margins offered by PKI are
fairly small and the initial investment required is fairly large.
Perhaps the margins will remain too small until royalty payments
can be eliminated entirely (until any patents expire) and the
FS companies can roll their own. Whether or not the margins
are too small, The FS companies can wait that long easily.
But the PKI vendor cannot wait. S/he will be out of business
in three or four years if nobody adopts. The patents will be
for sale then much cheaper than the royalty payments s/he is
offering, and the FS negotiator across the table knows it. The
PKI vendor therefore is going to get the worst end of the deal
every time s/he goes to financial services vendors, because s/he
is not dealing from a position of strength, and had best learn
the harsh lesson sooner rather than later.
A PKI will happen, eventually, but nobody is going to get into
a position where the financial-services sector depends on them
and has to pay them. That's as fundamental in business as the
second law of thermodynamics in physics, and chasing the dream
of becoming an indispensable monopoly to the financial services
sector promises to be as frustrating to the seekers as the quest
for a perpetual motion device.
Bear
CFP: PKI research workshop
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/26/2001 03:13 PM
To: cryptography@xxxxxxxx, SPKI Mailing List <spki@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
I doubt if fast/fstc participants would look at the following example
as a prime example .... but there are various "age" authentication
services that are available on the internet today ... basically
associated with adult entertainment ... but would also be applicable
to online gambling, various kinds of online purchases (alchohol), etc.
It doesn't have to identify who you are ... it just has to be able to
answer the question that you are at least of legal age.
now, it turns out that most of these services use effectively a
"loop-hole" in the current online credit card system to implement
their age authentication operation. There is such a thing in the
industry called a "one dollar auth". Credit card operations typically
have financial transactions authentication and authorized in real time
.... but the actual request for funds transfer is typically submitted
in batches ... at end of day or possibly end of shift. A "one dollar
auth" is an authorization request for a one dollar credit card
transaction, typically also with name & AVS (address verification)
data. If the name, account number, and AVS all verify .... and there
are no other outstanding problems .... then the request comes back
approved. The "age" authentication services typically are registering
individuals by requesting the information to perform a "one dollar
auth" .... where there is no subsequent batch submission for actual
funds tranfer. If the "one dollar auth" is approved, the age
authentication services take the result as indication of legal age
.... the credit card owner needing to have been of legal age to have
legally signed the credit card contract and obtained the credit cad in
the first place. Since no funds transfer actually takes place, nothing
shows up on the consumer's credit card bill. The age verification
service is charged a very nominal transaction fee for the "one dollar
auth" (along with the AVS transaction).
The age verification service then just packages that one time charge
into the fees that they charge their customers. They effectively
maintain a local "cache" of the answer to the "one dollar auth"
transaction.
I would contend that the evidence that such things are going on today
... is that the current system is "open" in the sense that it has open
standards (like ISO 8583) and lots of entities are making use of it.
In theory, one opportunity for FAST-like offerings is for the
financial industry to get directly into the age authentication service
business (in theory being able to do it at least as well with the data
as the 3rd party players out there today). A x9.59-like transaction
can be defined .... but in place of "dollar amount", there are
misc. other types of fields .... like "legal age". The consumer then
digitally signs the transaction and forwards it to the merchant or
server. The server takes the transactions and ejects it into the
appropriate authentication network (very much like credit card
transactions are done today) and gets back a "YES/NO" answerr (again
very much like credit card transactions happen today) .... the only
difference is instead of asking for consumer funds approval, the
merchant is asking question about legal age. Identity information
isn't being divulged ... not even date-of-birth ... which could raise
a serious identity fraud question .... just answerring YES/NO to the
legal age question. It could look like an X9.59 transaction, taste
like an X9.59 transaction ... but instead of having funds involved, it
has legal age involved.
It effectively creates an "open" online, authentication infrastructure
... requiring consumer to digital sign the transaction .... and a
recognized certification authority providing real time, non-privacy
invasive, answers. It otherwise has all the elements of an open public
key infrastructure (registration authorities, certification
authorities, consumers, relying parties, etc) w/o any certificates. In
that sense it is an online PKI paradigm .... rather than the
certificate-based offline PKI paradigm (which emulates the pre-70s
offline credit card infrastructure).
at 12/26/2001 2:36 pm wrote:
in addition to the x9.59 for all electronic payment transactions
... it is possible to extend online authentication where the
institution possibly isn't also responsible for the authorization
(and/or access privileges).... things like FAST projects in FSTC:
http://www.fstc.org/projects/fastaggregation.cfm
CFP: PKI research workshop
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/26/2001 06:26 PM
To: "Perry E. Metzger" <perry@xxxxxxxx>
cc: cryptography@xxxxxxxx, "Phillip Hallam-Baker" <hallam@xxxxxxxx>,
"SPKI Mailing List" <spki@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
for the most part HTTPS SSL is certificate manufacturing (a term we
coined a couple years ago) .... "infrastructure" typically implies the
administrative and management .... which would require (at a minimum)
CRLs for a certificate-based PKI.
the interesting thing about the use of SSL domain name server
certificates is that they supposedly are addressing an integrity issue
in the domain name infrastructure .... i.e. SSL checks that the domain
name listed in the SSL domain name server certificate is the same as
the domain name clicked/typed in for contacting the server. The issue
is that the domain name could be hijacked and instead of going to the
"real" IP-address .... it gets rerouted to a fraudulent IP-address.
however, if you track back the trust infrastructure for the SSL domain
name server certificate .... the process is somebody applies for a SSL
domain name server certifificate with a certification authority. The
standard operating procedure for certification authorities is that
they typically have to verify the information that they are certifying
(in this case domain name ownership) with the authoritative agency for
the information (in this case the domain name infrastructure). Now
since there could be an integrity problem in the domain name
infrastructure with respect to domain name hijacking ... there in fact
could be a domain name hijacking prior to the application for a
certificate .... which results in the issuing of a valid SSL domain
name server certificate to the wrong entity.
One of the suggestions for addressing the domain name infrastructure
integrity issue is for public keys to be registered at the same time
as the domain name .... and then further communication with the domain
name infrastructure be with digitally signed messages ... as part of
the process for thwarting domain name hijacking. Note however, since
the domain name infrastructure is the registration authority for the
public key as well as the relying party receiving the signed messages
.... certificates are redundant, superfluous, and extraneous .... even
tho it still could be considered a (certificate-less) "publick key
infrastructure" with significant administrative and management
support.
The other interesting aspect is that the existing domain name
infrastructure is set up for (presumably) trusted, (near) real-time
distribution (and updating) of almost any kind of information; not
just the (nearly) trusted binding of domain name to IP-address. Given
that public keys are also registered with domain names at the same
time as domain name and ip-address .... then a trusted domain name
infrastructure could be relied upon to implement a (certificate-less)
near real-time "public key infrastructure" (with full administrative
and management functions already in existance) .... aka the domain
name infrastructure could optionally distribute public key in the same
response that it distributes ip-address ...... eliminating the
requirement for a certificate-based PKI for trusted public key
distribution.
This is somewhat a catch-22 .... that one of the solutions to
addressing a basic SSL domain name certificate integrity problem
(i.e. a CA has a broken trust chain if there is an integrity issue
with the authoritative agency responsible for the information that a
certification authority must certificate) could also be the solution
eliminating any requirement for SSL domain name certificates.
As an aside, having the public key at the same time as the ip-address
for setting up the base TCP session could also be used to simplify the
normal SSL session setup (since there is no certificate distribution
that has to occur).
random additional discussion:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
there is also the claim that 99.99999 percent of client authentication
in the internet world today is radius-based; typically userid/password
(although radius supports multiple authentication processes
specifiable at an individual userid/account level). There has been
work done on an authentication process for radius involving digital
signature where a public key is registered in place of a
password. This would also represent a (certificate-less) public key
infrastructure with full administrative and management support.
random radius discussion
https://www.garlic.com/~lynn/subpubkey.html#radius
for pointer to radius standards & documents:
https://www.garlic.com/~lynn/rfcietff.htm
& click on Term (term->RFC#)
and then click on "RADIUS" in the Acronym fastpath section
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
also of some interest are the AAA rfcs:
Authentication, Authorization and Accounting
see also accounting , authentication , authorization
3127 2989 2977 2906 2905 2904 2903
perry e. metzger on 12/26/2001 3:45 pm wrote:
HTTPS SSL does not use PKI. SSL at best has this weird system in which
Verisign has somehow managed to charge web sites a toll for the use of
SSL even though for the most part the certificates assure the users of
nothing whatsoever. (If you don't believe me about the assurance
levels, read a Verisign cert practice statement sometime.)
Of course, client side certificates barely even exist, although people
made substantial preparation for them early on in the history of all
of this.
Were it not for historical accident no one would care about "PKI" in
this context.
> S/MIME use is significant and growing.
I get PGP encrypted mail a few times a week. I've never received a
request from any counterparty to set myself up to receive S/MIME. Your
mileage may vary.
> The financial industry is not looking at offline PKI models in
> general.
When I was still doing security consulting, nearly every firm I worked
for had installed Entrust or something similar -- and none of them
used the systems for anything.
PKI and the Emperor's New Clothes have a bunch in common.
> As for what PKI vendors have been up to, the sucessful ones have been
> supporting private label certification hierarchies from the start.
The PKI vendors are, I think, largely surprised by what has
happened. They were expecting things like lots of mutual
authentication using PKI to be in place, and in fact, there's almost
none in use at all.
I think many of the PKI vendors haven't been doing too well -- some of
them that I used to have dealings with barely exist any longer. The
one business that seems to make money is charging a toll for running
an e-commerce site. I wonder who they might be.
Of course, none of this should be surprising in the least. Commerce
and the PKI model have nearly nothing to do with each other. Some of
us were writing about this years ago.
Perry E. Metzger perry@xxxxxxxx
CFP: PKI research workshop
From: Lynn Wheeler
Date: 12/27/2001 08:22 AM
To: Ben Laurie <ben@xxxxxxxx>
cc: cryptography@xxxxxxxx, Nelson Minar <nelson@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
it isn't that you move it to a central authority .... you move it to
an authority that typically is already established in association with
authorization ... aka in normal business operation, a business
relationship is established that typically consists of creating an
account record that has various privileges associated with that
account/entity. For authentication purposes a public key can be bound
to that account and/or set of privileges. This goes on in the world
today .... and would continue to regardless of whether x.509 identity
certificates were issued or not. given that businesses have to play
the registration function for authorization & privileges ... aka
normal procedure doesn't allow somebody to walk into a random bank and
withdraw funds from a random account ... regardless of who they are
... aka identity doesn't magically enable a person to withdraw funds
from an arbritrary account ... ability to withdraw funds typically is
a privilege associated with whether or not some entity is authorized
to perform that function for a specific account. As such, the
financial institution has to register lots of information for the
account ... also registering a public key is consistent with the
existing business processes, liability, administrative and management
infrastructure.
In effect, large numbers of business processes already exist for
registration, administration, and management of authentication
information .... and having a certificate in the loop doesn't
eliminate those business processes (whether or not I had a certificate
.... there still would have to be something registered that some
attribute of "me" has authorization to do certain things). Doing
business flow and informatioin management optimization just
demonstrates that given existing business infrastructures for
registration, administration and management which also includes
certificates it is usually trivially possible to demonstrate that the
actual certificates are redundant, superfluous and extraneous ... aka
directly registering the public key and providing direct binding
between the authentication process and the authorization process
.... eliminating a possibly huge number of extraneous and unnecessary
business entities and business processes associated with
certificate-based operation.
There doesn't have to be any single central authority in a
certificate-less model. There can be all sorts of authorities for all
sorts of infomation .... which could be also hypothesized for a
certificate-based certification and authentication model. However, the
certificate-less exercise typically trivially demonstrates that any
certificate-based solution duplicates existing business processes
which aren't going to be eliminated. Therefor, it is then possible to
demonstrate business optimization where the duplicate (certificate)
business processes can be eliminated as extraneous, redundant, and
superfluous.
on 12/27/2001 7:16 am wrote:
As for the certificate-less model - all this really does is move the
binding from something you can carry around with you to something that
has to be done by a central authority. It is not clear to me why this is
such a marvellous improvement. Unless you happen to want to own the
central authority, of course, which, unlike certificates and CAs, is far
harder to replicate privately and therefore, presumably, potentially
even more profitable than Verisign's cash cow.
Cheers,
Ben.
CFP: PKI research workshop
From: Lynn Wheeler
Date: 12/27/2001 04:08 PM
To: pgut001@xxxxxxxx (Peter Gutmann)
cc: crawdad@xxxxxxxx, cryptography@xxxxxxxx, spki@xxxxxxxx
Subject: Re: CFP: PKI research workshop
I would tend to make the statement even stronger.
large, complex legacy systems tend to have slow technology uptake. most of
the certification authorities can be deployed in simple demos w/o impacting
the legacy systems and business process (possibly as a front-end process
that is pealed off before turning things over to the legacy business
process).
if you have legacy business process designed to support millions or
hundreds of millions of customers ... then any change to that system tends
to be significantly more expensive than a stand-alone certification
authority demo for a couple hundred. The problem has been the cross over
from toy-demo to real production. In general, the legacy infrastructures
and business processes have been put into place for perfectly valid reasons
.... even if somewhat slow to change.
I'm acquanted with one example where a single screen update (as part of a
new function rollout) to a customer call-center supporting tens of million
customer environment cost more than a dozen or so certification authority
demo systems. The issue was that call center was highly optimized and had
significant investment to scale into handling tens of millions of customers
very, very efficiently. To optimize a single screen & get it integrated
into a real live production environment required some amount of investment.
Such things as customer call-centers (not to mention scalable customer
call centers, scalable administrative and management infrastructure, etc)
for a customer service oriented operation .... could be totally ignored
when testing purely demo operations.
However, even with the cost of modifying a legacy operation .... where
authentication is integrated into the standard every day business processes
.... is significantly cheaper than trying to treat authentication as an
independent service (and build a separate scalable infrastructure that
real customer service orientation involves).
As an aside point ... I've found very few business operations that go
around trying to perform authentication operations purely for the sake and
enjoyment of performing authentication operations. For the most part,
businesses will perform authentication operations (typically viewed as
overhead or cost issue) as part of some real, productive business service
(a revenue issue). I find it difficult to come up with a whole lot of
scenarios where cost overhead (authentication) operations are performed for
no business (revenue) purpose. As mentioned in prior posting
https://www.garlic.com/~lynn/aadsm9.htm#cfppki6
given that authentication is being performed as part of some business
process or function ... then it is normally trivial to show it is easier
to have authentication (even digital signature authentication) integrated
into such business processes .... and correspondingly easy to show that
certificate-based operations are redundant, superfluous and extraneous
(modulo the issue of toy demos are cheaper than modifying production
business operations).
pgut001@xxxxxxxx on 12/28/2001 3:41 am wrote:
Naah, it's the monorail/videophone/SST of security. Looks great at
the World Fair, but a bit difficult to turn into a reality outside the
fairgrounds.
Peter (who would like to say that observation was original, but it was
actually stolen from Scott Guthery).
CFP: PKI research workshop
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/28/2001 04:50 PM
To: Ray Dillinger <bear@xxxxxxxx>
cc: crawdad@xxxxxxxx, cryptography@xxxxxxxx,
Peter Gutmann <pgut001@xxxxxxxx>, spki@xxxxxxxx
Subject: Re: CFP: PKI research workshop
both atm debit network and domain name infrastructure care capable of
local caching .... so that timelyness is within seconds to minutes (or
a few hrs as parameter within the needs of the infrastructure). the
offline world for certificates is the analogy of the letters of credit
from the days of the sailing ships. near real time with managed
caching (with relying parties forced to deal with stale credentials
manufactured months or years in the past).
part of the issue in clearing is who has the "liability" at any
particular instance; in the case of debit network caching there are
very specific procedures and processes. Are you suggesting that the
certification industry will assume liability in the case of offline
clearing associated with mars colonilization?
the process tends to be authentication, authorization, and finally
settlement and clearing. sometimes authorization, settlement and
clearing can be batched. if you are really talking about the bank
account balance resides on the earth and the access is from mars
.... offline authentication (clearing really needs to know whether the
money actually exists or not .... regardless of whether or not you are
dealing with the owner of the account) doesn't get you clearing
.... and real clearing needs to know that the money really exists (not
just that a person is authenticated) ... and if the account balance is
on earth and it takes 30 minutes elapsed time to establish it ... then
that it what it takes.
More realistic is account balance caching at some near real-time
location on mars ... say within the parameters of the ATM withdrawal
limit.
At one point in the PKI evolution there was the proposal that there
could be certificates analogous to the '70s "signing limit" checks
.,... an attempt to create certificates that not only provided
authentication information but also some hypothetical useful
approximation to authorization information (aka not quite reqressing
totally to the pre-70s credit card model). The issue in the "signing
limit" checks was when they found people writing 200 $5000 (limit)
checks to get a million. What has been seen since that time is near
real-time purchasing department operation (including business purchase
cards that leverage the credit card system) to provide real-time
aggregation ... as opposed to sinlge event operation. In the ATM
machine withdrawal case, there are typically both single widthrawal
limits as well as daily aggregate withdrawal limits (aka the PKI
proposal for credit cards turned out to be a business process
regression to pre-70s and the PKI proposal for business checks turned
out to be a business process reqression to pre'80s).
Typically what you might have in a ATM withdrawal case .... with
foreign ATM machine (not your local bank) .... is that the owner of
the ATM machine is given a guarantee of funds from your financial
institution prior to the ATM machine releases paper money. Your bank
then effectively debits your account for the equivalent amount of
funds. Then typically sometime that evening, there is a settlement
operation where there is funds transfer from your bank to the
financial institution that owns the ATM.
An offline, stale certificate .... only (slightly) addresses the issue
of authentication .... say an identification certificate ... which
might not even provide a binding between you and any particular bank
or bank account. Some sort of binding between you, your bank, and
your bank account is needed .... just for the authentication phase of
what you are talking about. There is still the authorization phase
needed so that the owner of the ATM machine believes that it can
receive something (in return for spitting out paper bills). That
effectively has to find that there are actually sufficient funds in
your account.
So a more realistic scenario would be that there is possibly dual
account, one local and one on earth ... with funds floating back and
forth as needed in evening settlements. If you are on Mars there is
some local financial branch with local record of funds that you have
immediately available and which can authorize that amount of money.
A "local" financial branch implementation and a digital cash
implementation might have a number of similar useability attributes
.... aka from the standpoint of how local funds do you have
immediately available .... aka funds are transferred into you local
PDA as digital cash for immediate use .... or funds are transferred
into the local financial institution for immediate use.
ray dillinger on 12/28/2001 2:29 pm wrote:
The only case in which the PKI solution is not redundant is in
offline clearing. But getting your point-of-transaction online
is easier than paying attention to PKI.
I happen to like offline clearing -- it opens up the possibility of
new transaction types and doing transactions in places you couldn't
before. But the practical issue is, everybody who's interested in
electronic transactions of any kind is also interested in getting
online, and when PKI's were deployed in "developing" areas (south
africa) they got dumped just as soon as the area was developed
enough for communications to support online clearing.
On the principle of people refusing to adopt something until
it relieves pain, maybe we won't see a real PKI deployed until
we need to serve markets where speed-of-light delays make online
clearing impractical.
Mars, for example, is 3 to 22 light-minutes away. I don't imagine
someone using an ATM on Mars is going to want to wait 12 to 88
minutes for online clearing (more if the protocol is talky or the
bandwidth is busy...). So a martian colony might be the first
practical application of PKI and/or digital cash, assuming the
colonists want to do business with Earth companies. But a colony
looks pretty distant right now: we haven't even got an outpost
there yet.
Bear
CFP: PKI research workshop
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/29/2001 03:22 PM
To: Andrew Odlyzko <odlyzko@xxxxxxxx>
cc: cryptography@xxxxxxxx
Subject: Re: CFP: PKI research workshop
everyday life has a lot of cryptography ... for instance ... there is quite
a bit of cryptography involved in every debit transaction (every time you
get money from ATM machine or use point-of-sale terminal).
a lot of PKI revolves around the business process of strong authentication
.... where some aspects of cryptography happens to be used. A subset of
this saw extremely rapid uptake with regard to SSL and online shopping
(again quite a bit of cryptography in use, one might make a case that
cryptography should be like electronic dsitributors, everybody may have one
... but very few could actually build one from scratch or even know thay
actually have one). One might be tempted to make the observation that
uptake rate is much faster if it is filling a new need as opposed to trying
to change existing operation.
However, PKI industry seems to have tried to make public key cryptography
and certificates an "end in themselves". First off, certificates are a
solution to strong authentication in an offline environment (aka early '80s
offline email paradigm) which doesn't have a very good match to most of the
business processes that are in use today.
A PIN debit transaction involves the relying-party (the consumer's bank
both authenticating and authorizing the transaction .... authentication
based on something you have and something you know ... and authorization on
a combination of authentication, available funds, any previous transactions
today, the aggregate value of any current day transactions, etc). Digital
signature can improve the integrity of the existing PIN-debit based
operation and also expand the use to open/insecure network (i.e. the
existing PIN-debit is predicated on closed, secure network). This is what
NACHA (national cllearing house association ... aka typically regional and
national financial industry organizations that provide infrastructure for
bank-to-bank wholesale financial transfers) did in the debit demonstration
.... basically upgrading PIN-based cyrptography for authentication to
digital-signature cryptography for authentication (where a shared-secret
paradigm ... aka PIN-base was replaced with a non-shared-secret paradigm).
https://www.garlic.com/~lynn/x959.html#aads
There was no certificate necessary ... and, in fact, certificates aren't
really about cryptography, there are more about a specific kind of offline
business process (which is having difficulty finding a niche in an
increasingly online world).
Furthermore, not only is the offline-paradigm certificate model having a
difficulty finding a niche in an online world ... the idea of a purely
authentication business process is possibly having trouble finding its
niche
... referencing prior posting that most business tend to perform
authentication ... a cost overhead ... as part of some useful, productive
business process (not purely an end in itself)
https://www.garlic.com/~lynn/aadsm9.htm#cfppki7
One might envision a Monty Python Department of Authentication. Citizens
are asked to visit their local Department of Authentication every day,
state their name, and provide certificate/credential for proof of their
claimed identity. The Department of Authentication doesn't actually record
that they've prooved any identity and citizens aren't actually mandated to
show up. However, if the citizens do show up everyday to their local
Department of Authentication, it makes the DoA employees feel that they are
providing a useful service in the scheme of the universe (as well as
certificates/credentials that are voluntarily verified everyday are better
than ones that aren't ... something like pet rocks).
Now, an interesting thing might be regarding rapid uptake of general
security. One could contend that majority of the market believes that good,
strong security should be an attribute of the basic infrastructure ...
somewhat like the issue of automobile quality in the '70s, not going to pay
any more for it ... but would migrate to a manufactur that had
significantly better quality. You then have the 1) vendors that don't see
quality as worth while since they won't be able to charge more 2) new
vendors that would like to sell "quality" as a stand-alone attribute ...
not actually having to manufactur automobiles .... but somehow convince
customers that they can sell quality independent of any product, and 3)
vendors that feel that they can eventually gain market share by providing
better quality.
Substitute "security" and/or "PKI" in place of "quality".
Part of the issue is that security (and strong authentication) should be an
attribute of the basic infrastructure ... not something that exists by
itself in a vacuum.
odlyzko@xxxxxxxx on 12/28/2001 6:54 wrote:
Several of the comments about the slow uptake of PKI touch on what
seem to be two basic factors that are responsible for this phenomenon:
1. Cryptography does not fit human life styles easily. As an example,
truly secure systems would stop secretaries from forging their boss's
signatures, and this would bring all large beaucratic organizations to
a standstill.
2. Novel technologies take a long time to diffuse through society.
"Internet time" is a myth. As just one example, a news story I just
read was about the great success of online bill paying. This is all
very well and good, but weren't we supposed to have that a long time
ago? As a matter of fact, didn't Microsoft try to buy up Intuit back
in 1994 largely in order not to be deprived of the possibility of
controlling online payments? (I have two papers on this subject,
one a short one, "The myth of Internet time" that appeared in the
April 2001 issue of Technology Review, and a longer, more detailed
one, "The slow evolution of electronic publishing," published in
1997, that argue that consumer adoption rates are not noticeably
faster now than in the pre-Internet days. Both are available on
my home page.)
Andrew Odlyzko
CFP: PKI research workshop
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/30/2001 04:42 PM
To: cryptography@xxxxxxxx
Subject: Re: CFP: PKI research workshop
another aspect that overlaps PKIs and quality is the difference
between "application" code and "service" code .... turning an
application into a service can be hard .... possibly writing 4-10
times as much code as in the base application infrastructure .... and
very high-quality code .... dealing with potentially very complex
failure modes. Related thread (buffer overflow) has been running in
the sci.crypt newsgroups. .... partial reference:
https://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#90 Buffer overflow
also an older thread regarding "assurance" in application and digital signature authentication
https://www.garlic.com/~lynn/aadsm5.htm#asrn1 Assurance, e-commerce, and some x9.59
https://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59
https://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59
https://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, x9.59, etc
lynn.wheeler@xxxxxxxx at 12?29/2001 3:22 pm wrote:
Now, an interesting thing might be regarding rapid uptake of general
security. One could contend that majority of the market believes that
good, strong security should be an attribute of the basic
infrastructure ... somewhat like the issue of automobile quality in
the '70s, not going to pay any more for it ... but would migrate to a
manufactur that had significantly better quality. You then have the 1)
vendors that don't see quality as worth while since they won't be able
to charge more 2) new vendors that would like to sell "quality" as a
stand-alone attribute ... not actually having to manufactur
automobiles .... but somehow convince customers that they can sell
quality independent of any product, and 3) vendors that feel that they
can eventually gain market share by providing better quality.
Substitute "security" and/or "PKI" in place of "quality".
Part of the issue is that security (and strong authentication) should
be an attribute of the basic infrastructure ... not something that
exists by itself in a vacuum.
CFP: PKI research workshop
Refed: **, - **, - **
From: Lynn Wheeler
Date: 12/30/2001 05:01 PM
To: Ray Dillinger <bear@xxxxxxxx>, crawdad@xxxxxxxx,
cryptography@xxxxxxxx, Peter Gutmann <pgut001@xxxxxxxx>,
spki@xxxxxxxx
Subject: Re: CFP: PKI research workshop
somewhat as an aside .... the "gift" cards (and other flavors) that
you see at large percentage of retail check-out counters in the US are
effectively digital cash ... although the current incarnation results
in a different card at every retailer. however, they are online,
magstripe-based digital cash .... utilizing the same ubquituous
point-of-sale infrastructure as debit & credit (it is just that the
transaction routing goes to different online transaction processing
than credit & debit). The issue of whether or not it would be possible
to use any card at any merchant is more of a business rule issue than
a technology issue.
note from a higher assurance standpoint ... the x9.59 work is
applicable to all electronic transactions .... whether they are
credit, debit, e-check, OR (online) digital cash ... AND x9.59
transactions could flow over both existing ubiquituous point-of-sale
network and/or a ubiquituous internet network (or any other kind of
network).
random refs:
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/x959.html#aads
lynn.wheeler@xxxxxxxx on 12/28/2001 4:50 pm wrote:
A "local" financial branch implementation and a digital cash implementation
might have a number of similar useability attributes .... aka from the
standpoint of how local funds do you have immediately available .... aka
funds are transferred into you local PDA as digital cash for immediate use
.... or funds are transferred into the local financial institution for
immediate use.
CFP: PKI research workshop
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/30/2001 05:45 PM
To: pgut001@xxxxxxxx (Peter Gutmann)
cc: bear@xxxxxxxx, pgut001@xxxxxxxx, spki@xxxxxxxx
Subject: Re: CFP: PKI research workshop
all the stored value digital cash systems that i've looked at
.... whether "online" or "offline" ... with the cash deposited in
offline chips .... has the same "issuer" skewed characteristic (aka
whether the digital cash is in the chip or the digital cash is online
someplace .... the issuer benefit is nearly identical).
my wife and I were asked to do pass/swag at the development on some of
the offline digital cash operations (and had to do the end-to-end
business analysis) and the issuer benefits were nearly identical to
the online versions.
there everntually were words out of basil and some of the eu central
banks .... that they would tolerant the benefit while such
infrastructures were trying to achieve production operations .... but
at some point successful operations would be asked to "share(?)" or
split the benefit with the end consumer.
pgut001@xxxxxxxx at 12/31/2001 5:25 am wrote:
Uhh, no, they're several steps removed from a cash-equivalent, with
things heavily skewed in favour of the issuers. See the slashdot
thread about this at
http://slashdot.org/article.pl?sid=01/12/29/1414258&mode=thread
for a technical and legal analysis (yes, it is slashdot that has this,
just make sure you set your noise threshold to 1 or 2).
Peter.
Small/Secure Payment Business Models
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/31/2001 01:29 PM
To: Ronald Duncan <Ronald.Duncan@xxxxxxxx>
cc: ietf-trade@xxxxxxxx, Ronald Duncan <Ronald.Duncan@xxxxxxxx>,
'Steve Schear' <schear@xxxxxxxx>
Subject: Re: Small/Secure Payment Business Models
note that current gift & stored value cards found in large percentage
of the larger retail store check-out counters ... provide a very
inexpensive & successful "online" small payment model. They currently
use magstripe cards and operate within the same point-of-sale
infrastructure as debit & credit.
From a "secure" stand-point with respect to insecure networks ... they
suffer the current downside as debit on the internet. However, x9.59
https://www.garlic.com/~lynn/x959.html#x959
is designed to provide strong authentication for all electronic
payments (not just credit, debit, or e-echeck but ALL) in all
environments (point-of-sale, internet, non-internet, etc).
NACHA has already tested an "internet" secure atm/debit with the
aads/x9.59 model
https://www.garlic.com/~lynn/x959.html#aads
x9.59 is applicable to all the existing point-of-sale online
electronic payment infrastructures and provides the necessary security
for their operation over the internet .... aka X9.59 can be extended
to not only secure credit and secure debit .... but the very same
infrastructure can be extended to secure "stored-value" for small
payments (aka there are existing business process infrastructures that
already handle electronic small payments relatively efficiently
.... the issue is the ability to use the same X9.59 that is design to
secure all electronic payments .... to provide the additional security
necessary for operation over untrusted networks).
some related discussions in crypto mailing list:
https://www.garlic.com/~lynn/aadsm9.htm#cfppki11
https://www.garlic.com/~lynn/aadsm9.htm#cfppki12
AADS Postings and Posting Index,
next, previous
- home