Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next, previous
- home
- Basic credit-card payment question
- Basic credit-card payment question
- Basic credit-card payment question
- Basic credit-card payment question
- Digital signatures as proof
- Meaning of Non-repudiation
- Meaning of Non-repudiation
- Meaning of Non-repudiation
- Meaning of Non-repudiation
- Meaning of Non-repudiation
- Federated Identity Management: Sorting out the possibilities
- Meaning of Non-repudiation
- Meaning of Non-repudiation
- Words, Books, and Key Usage
- Meaning of Non-repudiation
- Meaning of Non-repudiation
- international financial standards (ISO TC68)
- Alternative to Microsoft Passport: Sunshine vs Hai
- IBM alternative to PKI?
- IBM alternative to PKI?
- IBM alternative to PKI?
- IBM alternative to PKI?
- IBM alternative to PKI?
- Proxy PKI. Was: IBM alternative to PKI?
- Proxy PKI. Was: IBM alternative to PKI?
- Proxy PKI. Was: IBM alternative to PKI?
- Proxy PKI
- Proxy PKI
- Proposal: A replacement for 3D Secure
- Proposal: A replacement for 3D Secure
- Proposal: A replacement for 3D Secure
- Proposal: A replacement for 3D Secure
- ALARMED ... Only Mostly Dead ... RIP PKI
- ALARMED ... Only Mostly Dead ... RIP PKI
- ALARMED ... Only Mostly Dead ... RIP PKI
- ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
- ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
- ALARMED ... Only Mostly Dead ... RIP PKI
- ALARMED ... Only Mostly Dead ... RIP PKI ... part II
- ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
- ALARMED ... Only Mostly Dead ... RIP PKI ... part II
- Royal Mail pulls plug on ViaCode digital certificate
- ALARMED ... Only Mostly Dead ... RIP PKI ... part III
- PKI: Only Mostly Dead
- Web site exposes credit card fraud
- Web site exposes credit card fraud
- Giuliani: ID cards won't curb freedoms
- maximize best case, worst case, or average case? (TCPA)
Basic credit-card payment question
From: Lynn Wheeler
Date: 04/19/2002 11:09 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>
Subject: Re: Basic credit-card payment question
it is a lot more complicated than that.
the merchant has a relationship with a mechant bank/acquier. the
merchant sends transactions to the merchant bank/acquier. The merchant
bank/acquier sends the transactions to the issuering bank. The
merchant bank approves/disapproves the transaction and sends the
response.
Usually sometime that night, the merchant bank/acquier does a batch
financial transaction to each issueing bank that has any money to be
sent to any merchant at that merchant bank. This is via one (or more)
of the wholesale settlement systems. Basically there can be a single
wholesale funds transfer from each issuing bank to that specific
acquiring bank. The acquiring bank then aggregates all incoming funds
and then credits the appropriate amounts to each merchant account.
The wholesale settlement networks are used to do bank-to-bank
financial transfers for a number of reasons, ACH (aka check), ATM
(debit), credit card, wire transfer, etc. In the case of credit card
transfers, the acquiring bank has the mapping between the merchant
credit identifier and the merchant bank account number. If a customer
knew the merchant bank account number ... they could execute a ACH
push ... either via a check or other means to that account. The
problem is how to reconcile a financial deposit in the merchant
account with a specific customer/merchant transaction. Various of the
EDI 8xx transactions have addressed some of this ... merchant gets a
bulk financial transaction with an ACH addenda record listing the
itemized details of individual accounts. An example might be
electronic payments to utility company. Given that the utility company
had setup the appropriate EDI mechanism ... they could get a single
bulk transfer for the amount transferred for that day ... with EDI ACH
addenda record giving the individual account numbers and amounts
involved in the transaction.
Some of the supply-chain management infrastructures associated with
purchase cards send detailed "credit card statement" to the
corporation electronically in EDI addenda record format so that the
corporation can reconcile billing with transactions.
When the merchant is initiating essentially a "pull" transaction
... it is easier for the merchant to correlate the payment with
specific customer transaction. For a customer initiated "push"
transaction (say via ACH push) .... the conventions aren't all in
place so that it is easy for a merchant to correlate a received
payment with a specific transaction (the various EDI applications that
support pushed ACH payments aren't really a consumer product). Just
doing the money transfer isn't sufficient ... the merchant has to
additioinally have the information that correlates specific payment
amount with specific transaction, purchase order, etc
Customers push monthly payments to all sorts of merchants ... but they
typically have a pre-established account at that merchant ... and the
incoming check includes the customer's account number statement for
that merchant. There is big business in payment drop-boxes where a 3rd
party outsourcer handles all the incoming checks and statements. They
may generate a single large EDI ACH addenda record with line item
detail for the account numbers, possibly names, and amounts for each
individual account ... so the merchant can reconcile accounts
receivable information. In some cases, some of the banking electronic
payments system are banks directly offering the service of some of the
drop-box operators.
on 4/19/2002 4:28 am wrote:
The common way to perform credit-card transactions is that the
merchant initiates the payment with the help of the customers' card (data).
Do credit-card enabled merchants have any possible way to receive
money through the credit-card networks through an off-line
operation performed by the customer though his/her issuer?
I.e. an account-to-account transaction run in the other direction?
That would be terrific!
Anders
Basic credit-card payment question
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/19/2002 11:23 AM
To: Sean Owens <sowens@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
internet-payments <internet-payments@xxxxxxxx>,
"'kjvella@xxxxxxxx'" <kjvella@xxxxxxxx>,
"'razorbacksean@xxxxxxxx'" <razorbacksean@xxxxxxxx>
Subject: RE: Basic credit-card payment question
current internet infrastructure:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59 ... fyi
https://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59 ... fyi
financial standards body standard for all electronic payment types
(credit, debit ach, atm, e-check, etc) in all environments (internet,
point-of-sale, non-internet, etc):
https://www.garlic.com/~lynn/x959.html#x959
the requirement given the x9a10 working group for x9.59 standard was
to preserve the integrity of the financial infrastructure for all
electronic retail payments without encryption (i.e. can have digital
signatures or other method for data integrity, but not necessary to
encrypt the data).
realted is the NACHA atm trials
https://www.garlic.com/~lynn/x959.html#aads
the aads chip strawman (at the above reference) has a booth at
cardtech/securetech next week in New Orleans.
on 4/19/2002 6:26 am wrote:
Kevin,
Interesting Scheme. Actually, from a transaction perspective, and
Cardholder Authentication, wouldn't it make sense to utilize a
cardholder verification scheme, comparable to Card swipe, that
effectively proves the card was on premise, and utilized by the
cardholder. Effectively, we're looking for a way to decrease
processing fee's.
The card orgs up the Discount % a merchant pays for MOTO transactions,
since eCommerce trans, are acquired as MOTO (more oft than not), then
fee's are the issue. Other than CVV2/CVC2 verification on MOTO trans,
what other form of Cardholder authentication can be utilized to verify
validity. The eWallet idea, is comparable to Virtual Cards. What if,
with your issuer from an online standpoint, payment could be initiated
electronically, via an Internet Banking scheme, for Authorization.
Effectively, when I want to perform and eCommerce tran, I log onto my
Bank, and initiate the payment, immediately from the Issuer to the
Acquirer. All Cardholder authentication is handled by the ISSUER,
verification is not needed from the Acquirer. This could follow an
eWallet structure for authentication and card selection and tran
processing.
Sean Owens
Euronet Worldwide
1027 Budapest
14-24 Horvat Utca
HUNGARY
Phone +36 1 224 1626
Mobile: +36 20 932 1635
on 4/19/2002 1:42 pm wrote:
>
>not really terrific from a convenience point of view as that would
>mean the end of our forum!!!!
>
>An idea can include minimising the number of merchants - in other
>words the credit cards of this world would have an ewallet company in
>each and every country and the card holder pays the ewallet company
>and uses his ewallet to buy on-line. The online shops need not be
>online with the card schemes just with the ewallet company to check
>funds. this might probably be better from a chargeback and security
>point of view..... kev
>
>Kevin J. Vella
>International Business Development
>e-shore - Terranet Limited
>http://www.e-shore.net <http://www.e-shore.net>
>e. kjvella@xxxxxxxx <mailto:kjvella@xxxxxxxx>
>t. +356 21 489400
>m. +356 7985 0000
>f. +356 21 489600
>
>Other Company Websites:
>http://www.e-shore.com.mt <http://www.e-shore.com.mt/>
>http://www.di-ve.com <http://www.di-ve.com/>
>http://www.terranet.com.mt <http://www.terranet.com.mt/>
>http://www.maltanet.net
>
>Postal Address:
>Dolphin Centre, Main Street,
>Balzan, Malta (GC) BZN 08
>
>on 4/19/2002 12:28 am wrote:
>>
>>The common way to perform credit-card transactions is that the
>>merchant initiates the payment with the help of the customers' card
>>(data).
>>
>>Do credit-card enabled merchants have any possible way to receive
>>money through the credit-card networks through an off-line operation
>>performed by the customer though his/her issuer? I.e. an
>>account-to-account transaction run in the other direction? That would
>>be terrific!
>>
>>Anders
Basic credit-card payment question
From: Lynn Wheeler
Date: 04/19/2002 11:53 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>, kjvella@xxxxxxxx
Subject: Re: Basic credit-card payment question
some of the b-to-b purchase cards do some of this type of stuff ...
including translating the statements (both back to the paid to
merchant and the paid from customer) into EDI 8xx format.
on 4/19/2002 7:31 am wrote:
Kevin,
My need for this is to be able to pay invoices using credit cards.
I.e. a merchant can in a B2B-scenario send an invoice requiring
either pre-payment to perform shipping, or this is just another way to
pay international low-dollar invoices. I.e. an alternative to Swift
or checks.
Anders
Basic credit-card payment question
From: Lynn Wheeler
Date: 04/20/2002 01:19 PM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>
Subject: Re: Basic credit-card payment question
note that the comment was taken somewhat out of context since the
original question was directed at a b-to-b scenario. misc. refs
(especially #2 below):
https://www.garlic.com/~lynn/aadsm11.htm#0 Basic credit card payment question
https://www.garlic.com/~lynn/aadsm11.htm#1 Basic credit card payment question
https://www.garlic.com/~lynn/aadsm11.htm#2 Basic credit card payment question
the problem has been the merchant matching the pushed payment with
invoice or transaction. it is somewhat easier when the merchant
presents the payment requests and gets back an answer. having the
payee push the payment .... requires some like EDI 8xx ACH addenda
record containing enuf infomration so that the merchant can correlate
with stuff like their accounts receivable system. Even payment cards
are a merchant presented business process. Some of the electronic bill
payment systems do this and have the ACH addenda record (that is for
merchants where the electronic bill payment processor doesn't have to
resort to printing & mailing a paper check because the merchant
doesn't have the facilities for processing a combined electronic
payment plus electronic statement/invoice detail information).
on 4/20/2002 5:59 am wrote:
--- begin forwarded text from Digital Bearer Settlement List
"David G.W. Birch" <dgw-lists@xxxxxxxx> wrote:
lynn.wheeler@xxxxxxxx e-said:
> If a customer knew the merchant bank
> account number ... they could execute a ACH push
Surely they would never do this, because of the guarantees and legal
protections (and frequent flier miles) associated with their credit card.
Try charging back a wire transfer.
Regards,
Dave Birch.
... My own opinion (I think!) given solely in my capacity as ...
... an interested member of the general public ...
... ...
... mail(at)birches.org ......... http://www.davebirch.org/ ...
--- end forwarded text
--
-----------------
R. A. Hettinga <mailto: rah@xxxxxxxx>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
AW: Digital signatures as proof
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/26/2002 12:36 PM
To: "Weber, Arnd" <Arnd.Weber@xxxxxxxx>
cc: 'Anders Rundgren ' <anders.rundgren@xxxxxxxx>,
'Clara Centeno ' <Clara.Centeno@xxxxxxxx>,
"'Gary W. Fresen '" <gfresen@xxxxxxxx>,
"'heikki.sundquist@xxxxxxxx '" <heikki.sundquist@xxxxxxxx>,
'''internet-payments ' ' ' <internet-payments@xxxxxxxx>
Subject: Re: AW: Digital signatures as proof
part of the EU finread standard .... seems to be chipcard readers that
have certified security modules comparable to POS terminals .... aka
class-4 terminals that include secure pinpads and secure displays.
there is the concept of hardware token holding a private key that is
never divulged and therefor the token can uniquely authenticate itself
(something you have). what finread doesn't quite get around to
specifying is a compareable mechanism in the terminal/reader to
uniquely authenticate itself .... with the transition to open network
... rather than VANs & other forms of private networks ... it is a
lot more difficult to accurately assure the integrity of the end-point
(aka is it really a class-4 terminal/reader).
x9.59 payment protocol for all types of payments in all types of
environments (aka not just credit on the internet) .... included the
provision that the end-point terminal also may be required to
authenticate itself as well as any hardware token.
we demo'ed such a hardware token & terminal combination this week at
securetech/cardtech (aka both the hardware token and the secure
terminal signing different kinds of transactions ... payment, access,
authorization, etc).
misc. recent security & finread threads
https://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
arnd.weber@xxxxxxxx on 4/24/2002 1:55 pm wrote:
I'm not sure. At least here in Europe we had "phantom transactions" at
ATMs. Reasons I remember have been eavesdropping of PINs, maintenance
errors, fake ATMs, etc. Today, it is hard to tell between somebody
whose ATM-PIN was attacked, and somebody who only claims that his PIN
was attacked. I think we have to anticipate that log-in procedures
into signature systems may also be attacked. Actually the difference
between using a local signature implementation in a networked
office-PC and using a server-based one may be small - the user doesn't
really control either system. But on the server-based system, by
definition other people have control of the password. And not all
transactions can easily be reversed, in particular not money
transations.
Meaning of Non-repudiation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/02/2002 02:53 PM
To: "Trevor Freeman" <trevorf@xxxxxxxx>
cc: "Denis Pinkas" <Denis.Pinkas@xxxxxxxx>,
"David P. Kemp" <dpkemp@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: RE: Meaning of Non-repudiation
the NR bit in a certificate seems to be almost totally unrelated to
whether a person really intended for a signature to occur. within the
chipcard domain (on the way to showing non-repudiation need to first
establish intention &/or approval) ... there has been two different
kinds of ... lets say personalities;
1) access card personality .... the card powers on, a PIN is entered,
and the card signs an unlimited number of messages ... as an
authentication indication; from 3-factor authentication: two factors,
a) something you have and b) something you know.
2) financial card personality ... the card requires that a PIN be
entered for every signature; this has an implicit "intention" or
"approval" in addition to authentication; the card has the aspect of
an access card personality (2-factor authentication) as well as the
additional implicit aspect of "intention" or "approval" because a
human interaction is required for every signature ... aka the re-entry
of the PIN for every signature implying intention. The finread reader
standard goes further ... in that there needs to be a "secure" card
acceptor device with secure display & secure pin-entry (further
increasing the probability that the specific human was involved in the
re-entry of the PIN ... and it was done specifically in conjunction
with a specific transaction being displayed).
Having a "NR" flag in a certificate seems to have little or no bearing
on whether there is an implicit intention of a person that a specific
signature be performed (in the sense of a chipcard with a "financial"
personality that carries with it some action implying approval or
intention).
misc. past "intention" post (aka before getting to non-repudiation ... need
to first establish something like intention &/or approval before there is a
basis for repudiation or non-repudiation):
https://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
https://www.garlic.com/~lynn/2001g.html#60 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/2001j.html#7 No Trusted Viewer possible?
misc. past finread posts:
https://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
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
https://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
trevor freeman on 5/2/2002 12:52 pm wrote:
I am breaking one of my New Year resolutions by mailing on this topic,
but here goes...
Signing anything is always a challenge to prove position of a private
key to authenticate whether it's in the context of a protocol like SSL
or over a SMIME message. Technically all we can say is the signature
occurred. The intent behind why the signature occurred is beyond the
scope of this discussion. Use of certificates with the NR bit asserted
is ultimately a matter of local policy on what constitutes usage as
part of a non-repudiation service since two organisations could have
two separate non-repudiation service where one requires a NR signature
as part of an SSL session, and the other only wants NR signatures over
SMIME messages.
Never in the course of IETF has history so much been written over
something so small.
Trevor
Meaning of Non-repudiation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/03/2002 11:48 AM
To: ietf-pkix@xxxxxxxx
cc: epay@xxxxxxxx
Subject: RE: Meaning of Non-repudiation
in the X9A10 working group (for financial payment standards)
provisions were made for a token acceptor device to also be able to
sign a transaction. the operational characteristic of the token
acceptor device (like finread standard) would be registered (RA; with
or w/o a certificate necessary) which would indicate whether it
operated in such a manner as to require a human interaction implying
intention.
a simple hardware token digital signature by itself wasn't sufficient
for implying intention (a necessary pre-requisite before even talking
about NR) ... but the process around the execution of the token
digital signature was also necessary for implying intention. A finread
complient reader provides basis for inferring intention ... but then
you still need proof that such a reader was used for the specific
transaction (either because of some physical boundary, like ATM
machines on private networks ... or because the token acceptance
device is certified and also signs the transaction).
whether or not the digital signing environment was operated according
to acceptable mechanism for implying intention ... is pretty much
independent of whether there is a NR bit flag in a certificate. The
additional signature by a complient/registered token acceptor device
attests to the fact that specific operations were actually observed in
conjunction with the specific signing operation that might then be
used to imply intention on part of a person (as a necessary
prerequisite for any attempt at establishing non-repudiation).
Nominally a person would have to make some indication as to their
intention ... that could be done up front to a device ... which would
then know to also only select a public key that had a certificate with
a NR bit set. Note however, it isn't whether a certificate with a NR
flag that is important ... it is important that the process of
performing the digital signature followed precedures necessary for
infering intention (and some registered device can attest to the
intention infering process was followed).
__________________
previous ref:
2) financial card personality ... the card requires that a PIN be
entered for every signature; this has an implicit "intention" or
"approval" in addition to authentication; the card has the aspect of
an access card personality (2-factor authentication) as well as the
additional implicit aspect of "intention" or "approval" because a
human interaction is required for every signature ... aka the re-entry
of the PIN for every signature implying intention. The finread reader
standard goes further ... in that there needs to be a "secure" card
acceptor device with secure display & secure pin-entry (further
increasing the probability that the specific human was involved in the
re-entry of the PIN ... and it was done specifically in conjunction
with a specific transaction being displayed).
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of non-repudiation
Meaning of Non-repudiation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/04/2002 10:00 AM
To: "Santosh Chokhani" <chokhani@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, "'Trevor Freeman'" <trevorf@xxxxxxxx>,
epay@xxxxxxxx
Subject: RE: Meaning of Non-repudiation
i still think the semantics are confusing .... rather than random
challenges ... lets say authentication vis-a-vis
approval/agreement/intention ... is much more sensible semantics from
business and/or process orientation.
an authentication could be a radius implementation sending
time-value LOGIN:
the respondent creates a PPP radius response that includes the
time-value, the entities userid and a FIPS-186 digital
signature. FIPS186 digital signature contains a random component by
definition. simple authentication, no sense of
approval/agreement/intention.
this is as opposed to something like a financial transaction or other
physical signature analog that carries with it the sense of human
approval/agreement/intention. non-repudiation is something of a legal
issue that may use something about human approval or intention as part
of proving something. An electronic device that performs digital
signatures automagically doesn't carry with it the same implicit
connotation that a physical signature does ... which requires an
explicit human interaction. The human interaction of executing a
physical signature carries with it some concept that the person, in
fact intended to write the signature that they were writing. An
automagic electronic device creating digital signatures doesn't carry
with it the same connotation that the person was explicitly involved
in the execution of that specific digital signature.
From a process standpoint involving automagic electronic digital
signing devices ... there is no difference between the signing of
random bits and the signing of data. There may be a business reason to
distinquish between signature operations on challenge information
vis-a-vis signature operations on non-random data. However, in that
case, the signer should get to contribute a field to the signed
message indicating what it believes it is signing. Since an appended
certificate isn't part of the signed message ... it wouldn't directly
establish what the person believed (if they even knew) that they were
signing.
Trying to load a static certificate with semantic meaning as to what a
person believed to be signing ... for each signing operation
... leads down this garden path that there needs to be a unique
certificate for each possible signing business case ... and since a
static appended certificate can't directly indicate what a person
believe they were signing ... then there would also have to be a
unique public/private key pair for each possible certificate for each
possible business case. Given that you can proove that a person has
only registered a public key for one and only one type of business
process, and there exists one and only unique certificate for that
public key ... specificying one and only one unique signing business
process ... then you may be able to infer that the use of a
corresponding private key with the corresponding appended certificate
indicates what type of data the person believed they were signing.
Moving the type of (business/process) data indication (that the person
believed they were signing) out of the certificate and into the
content of the signed message .... eliminates having to infer it from
a static appended certificate (along with the corresponding
requirement of being able to proove that a specific public/private key
pair has only been registered for a certificate with a unique business
type indication). Having a public/private key registered with
multiple different certificate business types .... or the same
certificate indicating multiple possible business uses (types of data
being signed) .... creates ambiquity as to what type of data the
person believed it was signing (i.e. no longer able to infer unique
type of data the person believed it was signing based on the business
use indications in the certificates(s)).
The issue of type of data the person believed it was signing (by
inferring it from their choice of a unique signing key that is
uniquely associated with each specific type of business data) is
orthogonal to the business process issue that may require some
physical act on part of a person in conjunction with a signing
operation which can be used to infer approval/agreement/intention for
the execution of that specific digital signature.
santosh chokhani on 5/4/2002 7:15 am wrote:
Let us call NR bit bit A and DS bit bit B.
You are welcome to show how you interpret the bits. What I am proposing
is as follows:
A = 0, B = 0 => The public key may not be used to verify signature on
data on random challenges.
A = 1, B = 0 => The public key may be used to verify signature on data,
but not on random challenges.
A = 0, B = 1 => The public key may not be used to verify signature on
data, but can be used to verify signature on random challenges.
A = 1, B = 1 => The public key may be used to verify signature on data
and can be used to verify signature on random challenges.
I suspect of these, case "c" may be the most controversial, if any. How
many implementations use case c and use the public key to verify the
signature on data?
Meaning of Non-repudiation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/06/2002 09:58 AM
To: ietf-pkix@xxxxxxxx, epay@xxxxxxxx
Subject: RE: Meaning of Non-repudiation
somewhat as aside, in theory the whole point of certificates & the
"certified" information is for use/reliance by relying parties.
having a
1) bit that says the sender believes that they are signing something
with no meaning (random data) and
2) diffferent bit that says the sender believes that they are signing
something with meaning (not random bits) containing some semantic
meaning with possible implication that the signing operation indicates
the sender is in some agreement with the contents of the signed
message.
backing those bits out of the actual signed message and into an
appended certificate could work if there was an exact one-to-one
correspondance between the key doing the signing and the appended
certificate. However, if it is a certificate with both of the bits on
... then it is somewhat defeating the purpose of having the bits
.... because the relying party no longer can rely on specific
deterministic meaning (aka the sender believes that they are signing
something with no meaning ... or signing something with meaning
... but relying party isn't able to tell which because both bits are
on, defeating the purpose of having the bits at all).
The other problem is being able to proove that sender has never
acquired multiple certificates for the same key pair with different
bits set. Since the appended certificates aren't part of the signed
message ... the sender could claim that they had appended the
certificate with the "no meaning message" ... and somebody substituted
a certificate the "no meaning" bit off and the "meaning" bit on. That
problem then suggests two extremes:
1) never allow people to generate their own keys and supply them to
3rd parties for certification. CAs can guarantee that key pairs are
never submitted for multiple certificates if they only certify random
keys that the CA generate themselves .. and that creating a new
certificate always requires generating a new key pair (unless there is
a global repository used by all CAs checking to see if a specific
key-pair had ever previously been certified).
2) moving the certificate inside the signed message. the reason to do
this is the original suggestion involving the flag bits indicating the
senders belief as to the flag indicating message type/characteristic
needs to be part of the signed message. moving the whole certificate
inside the signed message is somewhat overkill just to get a couple
bit indicators moved inside. this solution requires a convention that
signers always include flags indicating their belief as to the type of
message (people doing brain-dead signing of messages w/o looking at
the contents might get themselves into situation similar to people
signing blank checks or blank pieces of paper).
previous pieces of thread:
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
Meaning of Non-repudiation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/06/2002 11:59 AM
To: Denis Pinkas <Denis.Pinkas@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: Meaning of Non-repudiation
a "problem" is that certificates are suppose to be something that a
relying party ... can rely on ... because relying parties supposedly
can't directly trust the signer/sender.
if you are going to be able to always trust the signer/sender in all
things ... then why do you need certificates ... which certify
information by independent parties ... just trust the signer/sender
and completely do away with certificates.
says that the relying party can't trust the signer ... but can trust
the CA ... except it has to trust the signer to not have two
certificates with different meanings and the same key ... so that if
there is a dispute ... the signer can repudiate the transaction by
saying that the sender had sent the certificate with the "random data"
bit set ... but somebody substituted another certificate w/o the
random data bit set .... unless somebody gets a law passed saying a
signer can't repudiate a transaction if they ever had two different
certificates issued for the same key. Even at that, certificates don't
include the signature on the data in a certificate by the sender
... only by the CA ... what is to prevent the claim that some CA
generated an arbritrary certificate containing my public key ... w/o
adequately prooving the corresponding private key?
so the movement of all flags/indications ... especially related as to
the intention/belief of the sender associated with a specific message
... into the signed body of the message. In effect, if there is some
trust issue as to what I believe or intend ... then I need to have
explicitly signed it. If there is some dependency on some state with
respect to some specific signed message/content ... then the signer
can repudiate it if it isn't covered by the signature. That is
somewhat independent of whether a signer can also repudiate stuff
they've signed. This is specifically that signers can repudiate a "not
random bit" in an appended certificate that isn't actually part of the
signed message.
denis pinkas on 5/6/2002 10:42 am wrote:
It is the problem of the signer (not of the CA) to make sure that when
it uses these two different certificates, two different keys are being
used.
Federated Identity Management: Sorting out the possibilities
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/06/2002 09:49 PM
To: "Arnold G. Reinhold" <reinhold@xxxxxxxx>
cc: cryptography@xxxxxxxx, dcsb@xxxxxxxx
mac-crypto@xxxxxxxx, "R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: Federated Identity Management: Sorting out the possibilities
I believe RBAC is supposed to be more like at lattice or complex graph.
basically RBAC has been a KISS solution for security administration ...
some number of fine grain entitlements have been worked out for groupings
that match stylized job descriptions or roles. In theory, the issues of
things like insider fraud have all been worked out for the idealized RBAC
cases. It is possible to enumerate the fine grain entitlements with a large
matrix ... however the challenge for RBAC systems is working out all the
interdependencies and security/integrity failure modes ... which is more of
a complex graph.
Given that the insider fraud and security/integrity failure modes have been
worked out for the idealized single role cases ... then where are the
points of failure when there is possible collusion ... aka when failure
security modes involve the coorperation of two or more individuals ...
actually two or more roles .... either involving collusion between
individuals or situations were security administrators have to assign two
or more roles to the same individual because the idealized scenarios don't
actually handle all possible real world cases.
fine grain entitlements grouped for RBAC roles then become sub-graphs
of a complex aggregate graph, aka real issues of RBAC-like operations
isn't representing the fine grain entitlements as either matrix or
sparse matrix but the complex interrelationships and implications of
the entitlement aggregations (aka roles). the interrelationships of
entitlement aggregations is the things that lead towards complex
graphis ... and then towards multiple subgraphs when dealing with
multiple role aggregates. strict object encapsulation can fail to
recognize the interaction of specific nodes (using graph sematnics) of
individual entitlements; aka RBAC roles (entitlement aggregations) are
paradigm convinience for security administrators ... however the fraud
and integrity/security failures involve interactions of the individual
entitlements (aka KISS RBAC encapsulation for security administrators
doesn't obsolve security tools for dealing with fine-grain entitlement
interactions).
rows & columns show up in relational databases and spreadsheets ....
paradigms oriented towards addressing relatively straighforward accounting
problems. real-world problems frequently have problems being force fitted
to relational or spreadsheet models. Even RDBMS implementations with
operations encomposing multiple databases ... with each database
potentially have large number of tables ... normally can't represent the
federated data dictionary for all the tables in all the databases using
straight-forward relational semantics.
adding/deleting a single entitlement in a sparse matrix shouldn't be the
objective. adding/deleting an entitlement with all its complex interactions
with other entitlements gets to be an issue. start is simple pair-wise
issues (somewhat like simple drug interactions) ... and then proceed to
more complex integrity/security failure modes involving complex
interactions of three or more entitlements.
other paradigms for cataloging and maintain complex information may be
required .... like something like we do in attempting to mirror the IETF
process
https://www.garlic.com/~lynn/rfcietff.htm
or the complexities of taxonomies (& glossaries):
https://www.garlic.com/~lynn/index.html#glossary
btw, the merged security glossary in the above was updated with the nsa
intrusion glossary this weekend.
on 5/6/2002 1:19 pm wrote:
At 12:46 PM -0400 5/6/02, R. A. Hettinga wrote:
>http://www.simc-inc.org/archive0002/February02/Speakers/geer-keynote.htm
>
>
>Logging in to Wall Street
>Federated Identity Management: Sorting out the possibilities
>SIMC's Third Annual Security Meeting
>February 26, 2002
>
>Keynote Address
>
>Dr. Daniel Geer
>
>Chief Technology Officer
>@stake
>
This is an interesting talk, but I'd question one assumption. Dan writes:
...
>If you look at the access control problem, it is a matrix. The rows are
>requestors and the columns are objects of their desire. Linear growth in
>either or both means geometric growth in the number of table entries in
>that matrix. Oh, sure, you can cut down the number of rows through
>role-based collective nouns and you can cut down the number of columns
>through the object-oriented sense of the word inheritance, but the natural
>path is that of geometric growth in the matrix even where interrupted
>occasionally by a tactical fall back like RBAC.
Seems to me that this is a sparse matrix. Most requesters have a
default status with regard to most objects. So the storage size of
this matrix is the number of requesters times the number of managed
objects per requester. That doesn't seem nearly as unmanageable.
And presumably the objects being managed have some value. The cost of
adding and maintaining one more cell to store an individual's status
regarding a particular object should simply be added to the cost of
her gaining access to that object.
Arnold Reinhold
Meaning of Non-repudiation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/07/2002 11:28 AM
To: Sharon Boeyen <sharon.boeyen@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx,
<osidirectory@xxxxxxxx>,
"Bill Burr (E-mail)" <william.burr@xxxxxxxx>
Subject: Re: Meaning of Non-repudiation
so the bit in the certificate just means that the CA dsavows all
knowledge of the private key ... aka "private key not divulged".
then possibly if it can be prooven that the private key was also not
divulged to anybody else ... then some conditions for meeting
non-repudiation requirements might be met (i.e. a CA not having
knowledge of the private key is several steps removed from
non-repudiation).
as aside ... definition for non-repudiation (from nsa intrustion
glossary) and non-repudiation sevice (from rfc2828) are in merged
security glossary:
https://www.garlic.com/~lynn/secure.htm
... quick path is to click on "PAIN" in Acronym fastpath ... and then click
on non-repudiation.
on 5/7/2002 7:28 am wrote:
I'd like to introduce another perspective on this topic, one that I really
think helps add some fundamental clarity to the topic. During the US FPKI
TWG meeting last week, this topic was raised and a short discussion was
held. Bill Burr commented that he understood the meaning of the
non-repudiation bit being set to be a statement by the certificate issuer
(CA) that they at no point had any access to the private key corresponding
to the public key being certified. I really like this because it states
what role this bit plays in a non-repudiation context. It is simply that
and nothing more. The remaining mechanisms for supporting a non-repudiation
service are outside the scope of the definition of this bit. Legal and
policy schemes can determine the behaviour of relying parties and users
when this bit is set. The bit itself cannot do that. If an assertion that a
user who signed something "knew and intended to sign whatever", then that
assertion should be something that accompanies a specific signature. This
bit cannot be expected to act as that assertion.
I also agree with Stefan that we need describe the digital signature bit
separate from the description of the non-repudiation bit in 509. Then it is
left to profiling groups, as it shoud be, what combinations of bits they
want set in their own environments.
Re the debate on changing the meaning - The reason we are having this
discussion (at least one of the reasons) is because the meaning of these
bits is not clear to many readers. Both the process of defect reports as
well as the enhancement process allows us to clarify text in the standard,
as well as to fix bugs etc). Part of the problem is that there isn't
agreement on what the original text meant, hence the clarification. Once
there is some sort of agreement on what the "right thing to do" is, then
we'll determine what the process is to achieve the intended result. That's
part of the reason why we are having the discussion before writing up a DR
or an enhancement request.
Sharon
Sharon Boeyen
Principal, Advanced Security
Tel: 613 270 3181
www.entrust.com
Entrust, Inc.
Securing the Internet
Meaning of Non-repudiation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/07/2002 02:21 PM
To: ietf-pkix@xxxxxxxx,
"500 list (E-mail)" <osidirectory@xxxxxxxx>,
Sharon Boeyen <sharon.boeyen@xxxxxxxx>,
"Bill Burr (E-mail)" <william.burr@xxxxxxxx>
Subject: Re: Meaning of Non-repudiation
sorry, finger fumble with the keys ... or the fingers moving faster than the brain.
https://www.garlic.com/~lynn/secure.htm
is the merged security glossary.
for more info about merged glossaries and sources see:
https://www.garlic.com/~lynn/index.html#glossary
lynn.wheeler@xxxxxxxx on 5/7/2002 11:28 am wrote:
as aside ... definition for non-repudiation (from nsa intrustion glossary)
and non-repudiation sevice (from rfc2828) are in merged security glossary:
https://www.garlic.com/~lynn/secure.htm
... quick path is to click on "PAIN" in Acronym fastpath ... and then click
on non-repudiation.
Words, Books, and Key Usage
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/07/2002 05:21 PM
To: "Trevor Freeman" <trevorf@xxxxxxxx>
cc: "David P. Kemp" <dpkemp@xxxxxxxx>,
ietf-pkix@xxxxxxxx
Subject: RE: Words, Books, and Key Usage
however, it is possible that a label for a bit has some semantic meaning
that is no way related to the feature/function implemented for the bit.
If the bit means that the CA has never seen the originator's private key
... it is possible for the CA to certify that by turning the bit on in a
certificate, signing the certificate and attesting to the fact that the CA
has never seen the originator's private key.
If the originator wants to have a certificate that has a bit turned on
indicating the originator's intention not to have ever shared the private
key with anybody ... then possibly, the originator can sign a message sent
to the CA with that assertion; the CA just copies the assertion to its
certificate ... not actually certifying anything other than it has copied
some assertion by the originator into the certificate.
The NSA Intrustion glossary
non-repudiation
Method by which the sender of data is provided with proof of delivery and
the recipient is assured of the sender's identity, so that neither can
later deny having processed the data.
obviously, the CA turning on a bit in a certificate doesn't meet that
definition. somewhere lurking behind the scenes is the stuff about being
able to disproving non-repudiation by showing that entities other than the
sender may have had access to the private key. Having the CA certify that
they have no knowledge of the private key (at least at the time of the
creation of the certificate) ... isn't an exhaustive proof that there is
nobody else that might have knowledge of the private key (or that the CA
might acquire knowledge of the private key in the future).
earlier parts of this thread also brought up non-repudiation in the context
of "processing" signed data ... which might imply some agreement or
intention regarding any possible semantic meaning of the data processed.
The simplest is being able to demonstrate that the sender sent the data ...
w/o implying anything about any knowledge, intention, and/or agreement that
the sender might have with regard to the semantic meaning of the data
transmitted. Being able to show that somebody else could have sent the
message ... would obviously negate assertions about non-repudiation.
However, not being to find anybody else with knowledge of the private key
... isn't necessary proof that there isn't somebody else with knowledge of
the private key. Also, even if it is possible to proove that nobody else
has knowledge or access of the private key ... doesn't proove that the
sender did anything else but transmit the data .... it doesn't proove any
knowledge or processing of the data ... other than the transmission.
in any case, the bit seems to represent a meaning that isn't consistent
with the meaning of the label applied to the bit (aka non-repudiation).
somewhat total aside did have a booth a couple weeks ago in new orleans at
cardtech/securetech with a hardware token where there is public/private
key-pair generated in the chip ... and the private key is never divulged
(leaves the chip) ... basically aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads
with couple twists ... like PIN-mode (and shortly biometric-scoring-mode)
operation ... and able to operate in both access & financial token
personality mode (aka earlier post in this thread):
https://www.garlic.com/~lynn/aadsm11.htm#5
<trevorf@xxxxxxxx on 5/7/2002 2:55 pm wrote:
Dave,
Semantics
1) The branch of linguistics and logic concerned with meaning
2) The meaning of a word, phrase, sentence or text.
Concise Oxford English Dictionary - Queens English edition
If you are changing the meaning of bits when they are asserted in an
extension, then its semantics not structure we are dealing with. I don't
dispute that the semantics behind non-repudiation are a little fuzzy to
say the least, but there are some basic ground rules in there which have
been agreed and included in RFCs. If you want to define new semantics
with cleaner definitions, feel free to do so, but you cannot do so
within the confines of the existing extension as identified by the
existing OID. I don't have a problem with what you are doing, just don't
do it in such a way as you break existing standards.
Trevor
Meaning of Non-repudiation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/11/2002 11:44 PM
To: Sharon Boeyen <sharon.boeyen@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, "500 list (E-mail)" <osidirectory@xxxxxxxx>,
epay@xxxxxxxx, "Bill Burr (E-mail)" <william.burr@xxxxxxxx>
Subject: Re: Meaning of Non-repudiation
while i was at it, i thot i would go ahead and update the merged security
glossary with the latest from ISO SC27
https://www.garlic.com/~lynn/secure.htm
some of the new defintions (from merged security taxonomy/glossary; i'm
still working on taxonomy for many of the new terms in the latest sc27
glossary).
non-repudiation
A security service by which evidence is maintained so that the sender of
data and recipient of data cannot deny having participated in the
communication. [IATF] Method by which the sender of data is provided with
proof of delivery and the recipient is assured of the sender's identity, so
that neither can later deny having processed the data. [NSAINT] The ability
to prove an action or event has taken place, so that this event or action
cannot be repudiated later. [ISO/IEC PDTR 13335-1 (11/2001)] [sc27] The
reasonable assurance that a principal cannot deny being the originator of a
message after sending it. Non-repudiation is achieved by encrypting the
message digest using a principal's private key. The public key of the
principal must be certified by a trusted certification authority. [misc]
(see also Generic Security Services API, IT security, NRD token, NRO token,
NRS token, NRT token, assurance, defense-wide information assurance
program, digital signature, distinguishing identifier, information
assurance, invalidity date, non-repudiation exchange, non-repudiation
information, non-repudiation of creation, non-repudiation of delivery,
non-repudiation of knowledge, non-repudiation of origin, non-repudiation
of receipt, non-repudiation of sending, non-repudiation of submission,
non-repudiation of transport, non-repudiation policy, non-repudiation
token, notarization token, originator, proof, recipient, sandboxed
environment, secure single sign-on, certification authority, public-key
infrastructure, quality of protection) (includes non-repudiation service,
privacy, authentication, identification, integrity, non-repudiation,
privacy, authentication, identification, non-repudiation)
non-repudiation exchange
A sequence of one or more transfers of non-repudiation information (NRI)
for the purpose of non-repudiation. [ISO/IEC WD 13888-1 (11/2001)] [sc27]
(see also non-repudiation)
non-repudiation information
A set of information that may consist of the information about an event or
action for which evidence is to be generated and validated, the evidence
itself, and the non-repudiation policy in effect. [ISO/IEC WD 13888-1
(11/2001)] [sc27] (see also non-repudiation)
non-repudiation of creation
This service is intended to protect against an entity's false denial of
having created the content of a message (i.e. being responsible for the
content of a message). [ISO/IEC WD 13888-1 (11/2001)] Protection against an
entity's false denial of having created the content of a message (i.e.,
being responsible for the content of a message). [ISO/IEC 15945: 2002]
[sc27] (see also non-repudiation)
non-repudiation of delivery
This service is intended to protect against a recipient's false denial of
having received the message and recognised the content of a message.
[ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also non-repudiation)
non-repudiation of knowledge
This service is intended to protect against a recipient's false denial of
having taken notice of the content of a received message. [ISO/IEC WD
13888-1 (11/2001)] [sc27] (see also non-repudiation)
non-repudiation of origin
This service is intended to protect against the originator's false denial
of having approved the content of a message and of having sent a message.
[ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also non-repudiation)
non-repudiation of receipt
This service is intended to protect against a recipient's false denial of
having received a message. [ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also
non-repudiation)
non-repudiation of sending
This service is intended to protect against the sender's false denial of
having sent a message. [ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also
non-repudiation)
non-repudiation of submission
This service is intended to provide evidence that a delivery authority has
accepted the message for transmission. [ISO/IEC WD 13888-1 (11/2001)]
[sc27] (see also non-repudiation)
non-repudiation of transport
This service is intended to provide evidence for the message originator
that a delivery authority has delivered the message to the intended
recipient. [ISO/IEC WD 13888-1 (11/2001)] [sc27] (see also non-repudiation)
Meaning of Non-repudiation
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/12/2002 03:24 PM
To: epay@xxxxxxxx, ietf-pkix@xxxxxxxx,
"500 list (E-mail)" <osidirectory@xxxxxxxx>,
Sharon Boeyen <sharon.boeyen@xxxxxxxx>,
"Bill Burr (E-mail)" <william.burr@xxxxxxxx>
Subject: Re: Meaning of Non-repudiation
I've finished some more of the taxonomy .... SC27 is big on evidence,
proof, audit trails and time-stamping.
try clicking on "evidence" (new to the concept section at the start of
the glossary frame).
lynn.wheeler@xxxxxxxx on 5/11/2002 11:44 pm wrote:
while i was at it, i thot i would go ahead and update the merged security
glossary with the latest from ISO SC27
https://www.garlic.com/~lynn/secure.htm
some of the new defintions (from merged security taxonomy/glossary; i'm
still working on taxonomy for many of the new terms in the latest sc27
glossary).
international financial standards (ISO TC68)
From: Lynn Wheeler
Date: 05/13/2002 09:23 AM
To: internet-payments@xxxxxxxx
Subject: international financial standards (ISO TC68)
somewhat ABA, ANSI, & ISO fluff
===================================================
For Immediate Release
Contacts:
Cindy Fuller
Accredited Standards Committee,
X9, Incorporated
c/o American Bankers Association
(202) 663-5284
cfuller@xxxxxxxx
Staci Busby
First Data
(303) 967-7188
staci.busby@xxxxxxxx
Gene Kathol Named Leader of International Standards Group
Washington, 2002? Gene Kathol, vice president of global electronic
commerce and payment services leader First Data Corp., has been named chair
of Technical Committee 68 (TC 68) Financial Services, an official committee
of the International Standards Organization (ISO) headquartered in Geneva,
Switzerland. Mr. Kathol assumed the ISO post by unanimous acclamation of
the TC 68 membership during their recent annual meeting held in Delft,
Netherlands. The national standards organization, ASC X9, Inc. proposed
Mr. Kathol from among its USA advisory committee to serve as chair for
TC68.
The work of TC 68?to formulate banking, securities and other financial
services standards?is important to assisting worldwide commerce. The
global committee includes several working groups staffed by experts
representing 56 countries who prepare standards made up of written
processes and procedures for the banking and financial services industry.
Standards are documented agreements containing technical
specifications and other precise criteria to be used consistently as
guidelines, or definitions of characteristics, to ensure that products and
services are fit for their purpose. To date TC 68 has prepared 72 global
standards. The standards assist the international industry in ensuring that
financial transactions are efficient, accurate, secure and in the best
interest of the general public.
A fundamental example of an international standard is the credit card.
The standard format specifies shape and thickness as well as communications
elements for card processing. This assures that cards adhering to ISO
standards can be honored worldwide.
(more)
Gene Kathol Named Leader of International Standards Group, page 2
Mr. Kathol's involvement in financial services standards began in 1985
when he became active in his first US standards group?Accredited Standards
Committee X9, Incorporated (ASC X9?Financial Services) ? a group accredited
by the American National Standards Institute (ANSI).
Over the past eighteen years, Mr. Kathol and his company, First Data
Corp., have been very active in helping to establish financial industry
standards. Mr. Kathol has participated in or chaired several domestic work
groups, and held various management positions, including serving as chair
of a national standards group ? the Retail Electronic Financial
Transactions sub-committee from 1996 to 2001.
Committees TC 68 and ASC X9, Incorporated are the only industry forums
that bring together bankers, securities professionals, manufacturers,
regulators, associations, consultants and others from the financial
services arena to address technical issues, find the best solutions and
codify them as nationally and internationally accepted standards. The
American National Standards Institute (ANSI) accredited the current
secretariat in 1984, and the International Standards Organization (IS0)
accredited the TC 68 secretariat in 1986.
For information on financial industry standards, please contact Cindy
Fuller, via the Web site at
https://www.iso.org/committee/49650.html
(international) or
http://www.X9.org
(domestic).
Alternative to Microsoft Passport: Sunshine vs Hai
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/13/2002 10:17 AM
To: arti@xxxxxxxx
cc: internet-payments@xxxxxxxx
Subject: Re: Alternative to Microsoft Passport: Sunshine vs Hai
one of the vulnerabilities identified by the X9A10 working group
.... was that the account number was an unauthenticated shared-secret
at all .... aka evesdroping at anypoint in the infrastructure could
lead to fraudulent transactions. the most secure part of the current
infrastructure was the SSL transport of the data-in-flight .... the
least secure was all the data-at-rest copies of the account number
thru-out the infrastructure (not just at the consumers private
computer but at several other points in the infrastructure as well).
the approach taking by the working group in the x9.59 standards work
was to make the financial transaction authenticated (with
fips186-2/ecdsa) and only the account number was carried in the
transaction .... and that account number could only be used in
authenticated transaction. the result was that the account number no
longer was a shared-secret ... and there was no longer any fraud
concern regarding all the points in the infrastructure where that
account number might appear as data-at-rest in the clear (not just the
consumer's private PC).
random refs to various fraud/exploits:
https://www.garlic.com/~lynn/subintegrity.html#fraud
a specific discussion/thread
https://www.garlic.com/~lynn/2001j.html#5 E-commerce security??
arti@xxxxxxxx on 5/13/2002 7:01 am wrote:
Brent,
All this is interesting (from a theoretical point of view), but
forgive me if I think that the entire concept of your ActiveCheckout
applet misses the boat - in the real world. It is a well-established
fact that the least secure part of the "Internet world" is the
majority of PCs from which average users access cyberspace; most users
have neither the skill NOR THE INTEREST to properly protect their
systems, and the advent of DSL and cable modem connection (with their
permanent I.P. addresses) has obviously made the situation even far
worse!
As a result, the worst possible tack to take, IMHO, is to maintain
users' personal information (credit card numbers, etc.) on their own
machines - you might as well tattoo that information on their
foreheads! Frankly, I believe that your company has made exactly the
same mistake as Microsoft, which caused them to become so vilified -
you have emphasized convenience over security. Try to imagine that it
is not necessarily a "good thing" for users to have that level of
convenience when purchasing something online - and before you jump
into the fray and start arguing this point with me from a theoretical
basis, take note of the fact that, in a recent and very comprehensive
study carried out by U.C.L.A., it was found that 91% of online users
rated themselves as being somewhat or totally uncomfortable with the
idea of passing their financial information online at all! That is NOT
a minor blip which can be overcome by convincing all those misguided
people that they're wrong to be afraid, because of this "great new
technology" or that ...
Ask me sometime if I believe that there will EVER be a secure way to
store or transmit personal information safely online ...
Cheers,
John Vinokur
President
Payment Central Inc.
mailto:john@xxxxxxxx
---Original message---
BR>As you might agree, the business of authenticating internet
BR>payments needs to stay within a trusted domain such as financial
BR>institutions rather than a technology company such as Microsoft.
BR>However, most banks do not want to develop, manage or support
BR>additional technology for authenticating consumers over Internet
BR>channels.
BR>To this end we have developed a FREE applet, ActiveCheckout, which
BR>gives online consumers control of their identity including their
BR>credit card information. This allows the consumer to store their
BR>information on their local machine, rather than on Microsoft's
BR>Passport servers, and assists in transferring this information to
BR>websites during registrations or online purchases.
BR>The applet has the ability to communicate with issuing bank(s) for
BR>realtime authentication during online purchases. It currently
BR>supports MasterCard's SPA standard and we are in discussion with
BR>Visa regarding support for Verified by Visa (3-D secure). This
BR>could improve the security of Verified by Visa transactions by
BR>reducing the possibility of "man-in-the-middle" attacks.
BR>ActiveCheckout can be installed from http://checkout.gpayments.com/ and
BR>further information can be found at
BR>http://checkout.gpayments.com/faq.htm
BR>Our ActiveCheckout project was codenamed "Sunshine" as a direct response to
BR>Microsoft's Hailstorm initiative and you can even download a Sunshine character animation for the applet.
BR>We are always impressed with the quality of contributions made
BR>through this forum and consider the members to be among the leading
BR>thinkers in the ePayments industry. We would greatly appreciate and
BR>seriously consider any feedback that you may have regarding this
BR>applet approach to identity and authentication management for
BR>Internet payments.
BR>Regards,
BR>Brent Clark
BR>GPayments
IBM alternative to PKI?
From: Lynn Wheeler
Date: 05/15/2002 01:50 PM
To: <Liaquat.Khan@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: RE: IBM alternative to PKI?
there have been a number of things done for relying party
operations. for various of the relying-party-only certification
authority pilots done in europe and other countries .... it was
possible to show that the public key could be registered ... and it
wasn't even necessary to send the certificate back to the key owner
.... just put it in the relying partie's account record (i.e. they
were sending the certificate back to the key owner ... because there
was some COTS software that could be used ... but other than that it
served no useful business function).
is this in anyway related to the previous work on relying-party-only
pilots that have been done in europe?
on 5/15/2002 1:10 pm wrote:
This model came out of the work down by IBM and others as a part of
the TIE (Trust Infrastructure for Europe) project. It is based on
public key cryptography, but looking at things from a slight different
angle, i.e. from the viewpoint of the RP. I need to be careful on how
much I can say. Although there maybe publicly available information
out there somewhere.
Regards,
Liaquat Khan
IBM alternative to PKI?
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/16/2002 08:48 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Dean Adams" <da@xxxxxxxx>, ietf-pkix@xxxxxxxx,
Liaquat.Khan@xxxxxxxx
Subject: Re: IBM alternative to PKI?
my impression is that server-side signings are typically the desire
for putting in a "real" PKI infrastructure .... but single, large
roll-out of all the technology is an issue ... so the backends
implement real PKI, and there is a middle-man which interacts with the
clients in a more traditional (password) paradigm and the middle-man
acts as a proxy doing the PKI stuff on behalf of the client. At any
point, individual clients might be able to deploy their own PKI
operation and eliminate using the proxy (theory is that it facilitates
the transition from password-based paradigm to PKI-based paradigm by
not requiring all backends and all clients to make the paradigm
transition in a single, synchronous event).
Many of the EU and other relying-party-only PKI deployments were
addressing a different issue. They came to realize that the
traditional PKI identity certificates didn't address any of their
business needs ... the client was doing digital signature operations
and appending things that bore a little resemblence to identity
certificates ... enuf so that traditional PKI sottware might
work. However, other than the facilitating of traditional PKI software
... the certificates weren't not serving any actual business function.
The first case of server-side PKI isn't so much a PKI alternative
issue ... it is a traditional PKI roll-out/transition facilitor. I
believe the second case of experience from relying-party-only
certificates ... could be considered more of a PKI alternative issue
(i.e. discovery that certificates weren't serving any valid business
function).
anders.rundgren@xxxxxxxx on 5/16/2002 6:53 am wrote:
Liaquat
>This model came out of the work down by IBM and others as a part of the TIE
>(Trust Infrastructure for Europe) project. It is based on public key
>cryptography, but looking at things from a slight different angle, i.e. from
>the viewpoint of the RP. I need to be careful on how much I can say.
You just triggered my curiosity!
Is it fundamentally different to 3D Secure and SAML? I.e. schemes
where the client authenticates to a server-based PKI-thing that does
the actual work (signs resp. creates auth).
Anders
IBM alternative to PKI?
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/16/2002 10:59 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Dean Adams" <da@xxxxxxxx>, ietf-pkix@xxxxxxxx,
Liaquat.Khan@xxxxxxxx
Subject: Re: IBM alternative to PKI?
i.e. middle-man tends to represent transition/roll-out solutions
.... not security infrastructure solutions.
from traditional security
end-to-end
middle-man approaches tend to always negate any end-to-end attribute
additional steps represent additional vulnerabilities
middle-man approaches increase the number of steps/processes .... each
of which represent an additional vulnerability, each additional
vulnerability represents additional points of failure/fraud
only as strong as the weakest link
shared-secret password paradigm in series with digital signature isn't additive.
2-factor authentication
secret password (as opposed to shared-secret password) in conjunction
with hardware token (i.e. processing in parallel instead of in series)
represents a combination link (both hardware token and secret password
has to be compromised). a shared-secret password process in series
with a digital signature process can fail with just the shared-secret
password.
IBM alternative to PKI?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/16/2002 02:17 PM
To: Trevor Perrin <Tperrin@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
Dean Adams <da@xxxxxxxx>, ietf-pkix@xxxxxxxx,
Liaquat.Khan@xxxxxxxx
Subject: RE: IBM alternative to PKI?
but purely monitor/audit isn't usually a transition scenario also.
if you are looking at the financial "middle-man" given in the example
by anders ... the financial end-point already contains extensive audit
and dynamic risk management (i think there was an article in NYTimes
this week or last week about the neural net stuff that looks for
complex fraud patterns). Given end-to-end integrity and no
intermediate stand-in .... I would contend that the end-point risk
management can do a much better job of deciding whether or not to
approve a transaction ... based on more comprehensive understanding of
the situation ... that wouldn't be available to middleman processing.
the issue is if you have a no-security infrastructure ... then adding
a monitor for auditing purposes can be a risk management benefit. we
defined a bunch of that stuff back in the '80s for something we were
calling "middle-layer" ... sort of the precursor to 3-layer
architecture.
Note however, this doesn't have to be a middle-man in the transaction
processing sense ... in the current internet ... a packet can flow
thru a large number of nodes ... all of which can be doing monitoring
and auditing (do a traceroute sometime) ... but wouldn't be considered
a transaction processing middle-man ... in the sense that it takes in
a transation ... processes the semantics of that transaction and then
generates a different transaction.
The scenario example is that a client does a password transaction with
a middle-man ... the middle-man processes the password transaction and
then generates a totally different digitally signed transaction
... possibly even emulating that the transaction originated directly
from the client.
A purely intermediate monitor/audit environment with no "middle-man"
processing and end-to-end security would have the client directly
generating the digitally signed transaction and sending it all the way
thru to the processing end-point. It isn't the monitoring/audit that
descreases security, it is any middle-man processing interferring with
end-to-end integrity.
Another scenario was "SET". SET had relying-party-only certificates
with digitally signed transaction. A "SET" gateway .... accepted
incoming SET financial transactions, verified the certificate,
verified the signature, stripped everything out ... and generated a
standard ISO 8583 transactions .... with an additional flag indicating
whether or not the "SET" gateway believe the certificate and signature
to be correct. Then a consumer's financial institution was dependent
on the "flag" in deciding whether or not it was a valid transaction
(aka there wasn't any end-to-end integrity). Furthmore, I don't know
if any of the "SET" gateways that had any financial liability
associated with fraudulent transaction (i.e. what happens if they were
to lie). At one point one of the associations gave a talk at an ISO
meeting giving the number of 8583 transactions that had the "SET"
valid signature flag set .... and they could proove that there was no
cryptographic capability involved at all (i.e. it wasn't even a SET
gateway that might not be telling the truth ... but there were
financial reasons why others might want the flag set also).
now, I would claim that an end-point business operation might
compartmentilize some of its functions ... so that any compromize in
any single component doesn't compromise all components. i would
contend that a compartmentilzed end-point security solution is
different than several different business operations all implementing
various kinds of intermediate processing (middle-man) preventing any
kind of end-to-end integrity.
random old middleware/middle layer refs:
https://www.garlic.com/~lynn/96.html#16 middle layer
https://www.garlic.com/~lynn/96.html#17 middle layer
https://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
https://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
https://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33 Typing Element)
https://www.garlic.com/~lynn/99.html#201 Middleware - where did that come from?
https://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?
https://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
https://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
https://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
https://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
https://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic: facts vs. FUD
https://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
https://www.garlic.com/~lynn/2002.html#2 The demise of compaq
https://www.garlic.com/~lynn/2002.html#7 The demise of compaq
https://www.garlic.com/~lynn/2002.html#11 The demise of compaq
https://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002b.html#37 Poor Man's clustering idea
https://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
https://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002e.html#2 IBM's "old" boss speaks (was "new")
tprerin@xxxxxxxx on 5/16/2002 1:33 pm wrote:
Hi Lynn (and greetings to PKIX, 1st-time poster here),
A counter-argument: while adding a middleman adds a vulnerability, it also
adds auditing: the middleman can monitor all password attempts, so as to:
- lockout guessers
- detect anomalous patterns of use which may indicate a compromised
password is being exploited
- allow users to review audit trails to detect compromises themselves
- allow users to review audit trails to determine the extent of a
compromise
Without this auditing, it may be much more difficult to detect a
compromise of a private key, and to determine precisely what has been
compromised.
So there are security benefits as well as disadvantages to middlemen,
I suppose a comparison depends on the exact situation and how you
weight the factors..
Trevor
IBM alternative to PKI?
From: Lynn Wheeler
Date: 05/16/2002 03:15 PM
To: Trevor Perrin <Tperrin@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
Dean Adams <da@xxxxxxxx>, ietf-pkix@xxxxxxxx,
Liaquat.Khan@xxxxxxxx
Subject: RE: IBM alternative to PKI?
so lets do the counter argument in the business process sense ... a
middle-man that is a different company than the end-points (as opposed
to possibly middle-man implementation which is actually a business
entity's compartmentalized operation ... which has various
security/vulnerability trade-offs).
so in the business middle-man scenario ... the middle-man is your
strongest competitor/advisary. they process incoming transactions and
then generate something from scratch that is forwarded to you. you
have no way of prooving that the incoming transactions are fraudulent
or not. furthermore the business middle-man has no financial
penalty/liability with regard to fraudulent transactions.
Proxy PKI. Was: IBM alternative to PKI?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/17/2002 05:02 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Dean Adams" <da@xxxxxxxx>, ietf-pkix@xxxxxxxx,
Liaquat.Khan@xxxxxxxx
Subject: Re: Proxy PKI. Was: IBM alternative to PKI?
you can do server-based PKI in conjunction with multiple authorization
operations .... i.e. somebody uses a password to talk to a
server-based PKI ... and the server turns a password operation into a
PKI operation at the same time doing other organizational
functions. However, it would be a mistake to assume that because two
different operations are being performed by the same server ... that
one kind of operation (password to PKI translation) also inherits the
other kind of operation (say multiple approval level operations).
The counter example is an end-to-end security implementation where the
original client signs the transactions ... and if there are multiple
approvals required because of business reasons ... that the other
agents (human or software) along the way also sign the same
transaction ... providing end-to-end security for both the original
transaction as well as any intermediate approval steps.
If a organization has both a requirement for multiple level approval
and can't deploy real PKI out to the end clients ... that they could
implement both business functions in a single data processing unit.
Various scenarios for end-to-end security and multiple levels of
approval/signing are
1) in the NR thread in this list, I made reference to the EU FINREAD
standard for token acceptor device having secure display and secure
pin-entry ... as part of trying to close some of the NR-service gap
with respect to human intention .... i.e. all operations requiring
some indication of human intention in support of any NR ... required
that every signed transaction need to have been done with a hardware
token in conjunction with a FINREAD terminal configured such that
every transaction signing first required a person to first enter a
PIN. Provisions were made in the x9.59 standard that not only would
the originating client sign the financial transaction ... but the
"environment" that the signing took place in would also sign the
operation (i.e. not only could you claim that an EU FINREAD certified
device was used for the signing environment ... but you could proove
that an EU FINREAD certified device was used for the signing
environment .... because the certified device also signed the
transaction).
2) various kinds of workflow systems ... may require two or more
levels for final approval for purchase orders. The purchase order
business protocol can have that external business entities don't have
to actually authenticate the lower-level or originating digital
signatures .... but just the final approval agent that is responsible
for interfacing to external organizations. However, it can be useful
to carry the originating and intermediate digital signatures along
with the transaction as an internal audit trail.
Now it would be possible to implement such a function where all the
internal corporate processes were password based and that only
purchase orders (or other types of transactions) that actually left
the corporate boundaries carried a digital signature .... in effect
the digital signature of the final approval agent. I would claim that
any use of a unique signature per originating employee ... rather than
the digital signature of the approval function (human or software) is
an artificial fabrication. In this particular scenario, the trust is
between all the external business processes and the unit performing
the signing ... any use of unique signatures per originating employee
rather than a single signature of the signing authority is an
artificial fabrication. The only purpose of such an artificial
fabrication might be because we want to pretend that the trust
relationship is directly between the external units and the individual
employee (because there is a transition plan that employees will be
able to directly sign individual transactions and send them directly
to external agencies w/o any individual approval authority). Otherwise
the artificial fabrication is merely obfuscation ... internal audit
procedures will be able to tie individual password transactions to
specific approval transactions; each PO has unique identifier and
audit trail of all steps including relating to the originating
employee and their password transaction.
===============================================================
Bifurcating the end-to-end trust relationship with some passwords and
some PKI ... implies that there is different levels of trust between
the password-based trust relationship and the PKI-based trust
relationship. The bifurcation is either because 1) we are planning on
transitioning to a real end-to-end PKI relationship .... in which case
we create the artificial appearance of each originator signing with a
unique key as an aid to that transition or 2) there isn't any "real"
end-to-end trust relationship ever required, that the trust
infrastructure really is partitioned .... that password is sufficient
for "internal" operation and only the interface agent is ever going to
be signing, in which case only a single key is needed by that
interface agent. Since there is never going to be any real end-to-end
trust relationship ... the signing agent only needs a single
key. Having the server/signing agent sign with a different unique key
per originator is an artificial fabrication since there is actually no
end-to-end trust (or planned to be).
My original statement is that the server-based PKI is either an a) aid
to transition to individual key signing ... in which case there is a
point of creating the fabrication that there is some end-to-end trust
or b) a permanent solution ... if it is a permanent solution there is
no real point in creating the artificial fabrication of an end-to-end
trust relationship (with different key per originator) ... the trust
relationship is between the signing agent and the external agencies
... for the purposes of trust ... it is only sufficient that the
signing agent sign the operation because it would be a total
fabrication that there is an end-to-end PKI trust relationship between
the external entities and the individual. A properly designed business
process designed PKI-trust operation would have the keys belonging to
the operational entities being trusted. Any implication that the
PKI-trust boundaries are different (i.e. server signing agent using
individual associated signing keys) is an artificial fabrication that
would need some valid business justification ... like the planned
transition to real end-to-end PKI-trust boundaries. If there is never
going to be any real end-to-end PKI trust relationship ... and the
trust relationship is only between the signing agent and the external
entities then I would claim that multiple different keys (one per
originating employee) is superfluous.
There is also always the danger when creating artificial fabrications
that somebody might incorrectly believe there is a real end-to-end PKI
trust relationship that doesn't really exist. Business executives will
typically sign-off a risk acceptance when creating artificial
fabrication when it is shown that it is a temporary solution pending
transition to real implementation.
anders.rundgren@xxxxxxxx on 5/17/2002 3:31 am wrote:
Lynn,
That was a rather prejudiced description of server-based PKI.
There must be a reason why 42M people use Internet-banks just in
Europe. These banks serve as giant "proxies" and I don't see how
Internet-banks could ever be replaced by client-side PKI solutions!
Do you?
I.e. the use of a "middle-man" or "proxy" has other qualities than
just enabling PKI-transition/roll-out.
Another example are B2B-systems, where clients must perform
actions through the local business system which enforces the
authorization and policy rules. In addition to storing in- and out-
going business-messages. A structure that is in daily use since at
least 20 years back or more, so it is definitely time-proven.
And what's more, employees' privacy is protected by this arrangement.
By using server-PKI, companies and banks can abandon expensive
leased-lines and use the Internet. Probably with an increase in security
compared to today. Message integrity control is essentially for free
using PKI.
Server-PKI actually supports end-to-end security as well, although
there are two pair of end-points: client-to-proxy, proxy-to-rp.
When/If client-side PKI becomes ubiquitous, it just makes the link
between the proxy and client stronger. Including NR support in case
the proxy want to sue the client for malpractice. Or the reverse BTW.
I think the real discussion is really what constitutes an "end-point".
In B2B it does not have to be an individual as an individual is not
a company. Few PKI-lawyers understand this as companies cannot
"sign" in the paper-world. But in the "e-world" that's a piece of cake!
In case you want to try a B2B-system implementing server-based PKI,
using XML-Signatures for all B2B-communication, you are invited
to try out https://buyer.x-obi.com/BuyerASP/buyer
Properly written, and protected by firewalls, HW-crypto, and secured
physical facilities, such systems can work wonders. As Internet-banks
already do, and that on a massive scale.
The only "business" that so far has not fully grasped the usefulness
of using server-PKI is the public sector, but I stay confident that
they soon will, as running a government authority should be rather
similar to running a company. I.e. there are internal and external
communication, policies etc. that means that you must have a
"proxy" somewhere in your organization to maintain this in a
reasonable way. The net effect is the external communication
will be performed by the proxy rather than by the employees.
Cheers,
Anders
Proxy PKI. Was: IBM alternative to PKI?
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/17/2002 06:17 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Dean Adams" <da@xxxxxxxx>, ietf-pkix@xxxxxxxx,
Liaquat.Khan@xxxxxxxx
Subject: Re: Proxy PKI. Was: IBM alternative to PKI?
note that i believe all the original ipsec stuff was end-to-end
.... lightweight ipsec i believe was introduced with VPN at a router
working group at the fall '94 IETF meeting in San Jose (by somebody
who had originally built one for their personal use).
VPNs have some of the characteristics you claim for proxy PKI ... but
they don't claim to be signing stuff on behalf of other entities
... they have a specific trust model and the PKI mirrors the trust
model of the units involved in the trust operations. There is no
artificial fabrication that the VPN unit that does the signing as part
of a PKI trust operation is some totally other entity pretending to
fabricate some totally different trust operation.
VPNs also allow corporations to replace expensive leased lines with
internet connections.
bank-to-bank financial transfers don't happen under the pretend
signatures of the individual account holders. bank settlement has
uthentication between the two bank entities (either implicit, possibly
because of leased line, routing code, etc ... or explicit ... the
banks actual authentication process). As part of a bank-to-bank
transfer ... banks will include adenda records that break out the
individual accounting detail.
Proxy PKI. Was: IBM alternative to PKI?
From: Lynn Wheeler
Date: 05/17/2002 01:06 PM
To: Trevor Perrin <Tperrin@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
Dean Adams <da@xxxxxxxx>, ietf-pkix@xxxxxxxx,
Liaquat.Khan@xxxxxxxx
Subject: RE: Proxy PKI. Was: IBM alternative to PKI?
1) there isn't end-to-end integrity ... there is a chain of trust
.... that has to be stiched together to approx. some end-to-end
operation; then we are back to the original point about the security
being only as strong as the weakest link.
2) you can either be using password/pki security bifurcation as
a) transition solution not a security solution (as in the original
post) or
b) the approving agency signs something that the external agencies
trust ... (aka as in VPN) and the external agencies need to have
absolutely zero awareness about the internal machinations and internal
trust relationships, and/or
c) creating a total fabrication that individuals are really signing
stuff when they aren't.
The difference between "b" and "c" ... is that the relying parties are
really relying on the signing agency ... in "b" there is a one-to-one
relationship between the signature and the trust relationship ... and
in "c" the trust relationship is significantly obfuscated with lots of
different key pairs that contribute nothing to the intrinsic trust
infrastructure.
tperrin@xxxxxxxx on 5/17/2002 12:14 pm wrote:
Hi Lynn,
I agree that using a password<->PKI middleman doesn't provide
end-to-end PKI trust. But it could provide end-to-end trust, in the
sense that, when the middleman signs, he explicitly mentions the name
being signed for, or when something is encrypted to the middleman, it
explicitly includes the name the encrypted data is intended for.
Such a middleman would be a replacement for an identity
certificate/key pair, but it would not "artifically fabricate"
signatures by holding multiple keys, one for each client, but would
instead make honest statements such as "I authenticated Alice with a
password, and am signing this on her behalf".
The point, I guess, is that you can have end-to-end security (meaning
authenticated or confidential communications with end-users) without
end-to-end PKI, if you trust the PKI endpoints to make authentic
statements from, or deliver confidential statements to, end-users..
Proxy PKI
From: Lynn Wheeler
Date: 05/22/2002 09:41 AM
To: Trevor Perrin <Tperrin@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, owner-ietf-pkix@xxxxxxxx
Subject: RE: Proxy PKI.
and of course the other case for Proxy PKI is where there is a
hierarchy of trust .... like in B-to-B scenario and the proxy may
implement some number of business rules in addition to authentication
on subordinate trust units (like a corporate purchasing department
approval iinfrastructure). From a design standpoint the authentication
paradigm (password or digital signature) on inbound requests from
subordinate trust units should be transparent to the outbound digital
signed requests. top-level trust units (say in b-to-b corporate
scenario) shouldn't care about the internal trust mechanism and/or
even that their are subordinate trust units. This is sort-of like
inverting the standard CA trust hierarchy ... rather than the CA
distributing static proxy trust certificates to each individual
.... and each individual distributing the static proxy trust
certificates with each of their signed messages .... the individuals
send each authenticated message directly to the CA-equivalent ... and
the CA does real-time rules in addition to the authentication
operation before replacing the lower-level trust authentication with
their own digital signature and sending it on. In this sort-of
inverted trust paradigm, each message becomes a little like a
real-time certificate (and the originating subordinate trust unit
information doesn't even have to be propagated). The trust paradigm is
still with the entity applying the (final) digital signature
... regardless of whether it chooses to use a single key-pair or a
multitude of key-pairs creating the facade of multiple entities
(simulating each of its sub-ordinate trust units).
Proxy PKI
From: Lynn Wheeler
Date: 05/22/2002 12:03 PM
To: Trevor Perrin <Tperrin@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, owner-ietf-pkix@xxxxxxxx
Subject: RE: Proxy PKI.
aka from trust standpoint, the described proxy PKI is a certification
authority in disguise ... implying possibly it might be in need of things
like CPS.
Proposal: A replacement for 3D Secure
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 05/27/2002 11:49 AM
To: Sebastian Kübeck <kuebeck@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>
Subject: Re: Proposal: A replacement for 3D Secure
the x9a10 working committee (part of x9 financial standards body) was
given the charter of preserving the integrity of financial
infrastructure for all retail transactions (not just internet, not
just point-of-sale, etc.).
basically the result is X9.59 which is a light-weight digital
signature authentication that can be mapped into international
standard financial industry 8583 networks. basically it was done in
such a way that it provides for end-to-end digital signature
authentication and security ... being able to be mapped directly into
the actual international standard 8583 transactions on an end-to-end
basis from customer striaght thru to the customer's financial
institution. It isn't specific to internet and it isn't specific to
credit .... but is appicable to all retail payments (credit, debit,
stored, value, atm, etc) in all environments (POS, internet, atm,
etc).
the advantage is that the actual financial transaction is the thing
being authenticated on an end-to-end basis. there isn't a truncated
authentication that doesn't make it thru to the customer's (issuing)
financial institution. There isn't a separate authentication
transaction that is totally different from the actual financial
transaction. The actual financial transaction carries the
authentication of the financial transaction on an end-to-end
basis. There isn't any separate need for a different routing/lookup
mechanism for the authentication operation that travels totally
different from the actual transaction nominally when talking about
end-to-end authentication .... the normal reference is to the actual
transaction .... some of these proposals creates a totally different
transaction ... that flows via a totally different path ... and while
it might get from the client/customer to the customer's (issuing)
financial intitution ... it isn't an end-to-end secure financial
transaction ...... it is a totally different transaction (and doesn't
meet the nominal definition of end-to-end security).
random refs:
https://www.garlic.com/~lynn/x959.html#x959
also reference to the nacha/debit/atm pilot
https://www.garlic.com/~lynn/x959.html#aads
kuebeck@xxxxxxxx on 5/27/2002 at 1:43am wrote:
Hi Anders,
About the proposition:
I think the main problem of 3D Secure is that it's only an
authentication mechanism and not a payment protocol at all. Compared
to SET, the seperation auf authentication mechanism and payment
protocol is a huge step back.
About core technology:
it's interresting that in Jannuary, we had a similar idea. However,
we didn't think that the customer wants to remember the issuer's
domain, so we proposed a lookup mechanism (similar to DNS) mapping the
user's eMail adress to the domain of his/her issuing bank.
About the idea:
Great approach!
Yours,
Sebastian Kübeck
____________________________________________________
QENTA paymentsolutions sebastian kübeck
www.qenta.com kuebeck@xxxxxxxx
tel: +43 316 81 36 81-0 fax: +43 316 81 36 81-20
Proposal: A replacement for 3D Secure
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/27/2002 02:09 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments@xxxxxxxx
Subject: Re: Proposal: A replacement for 3D Secure
... following is in response to a private communication with regard to
X9.59 and information at the web site:
http://www.ca0.net/ Top Cat ANSI X9.59 Main Page
basically there is a signed payment instruction message ... that the
client sends to the merchant (either at POS or internet).
The appendix describes how that message can be mapped into a standard
8583 transaction by the merchant (credit, debit ... or even those
stored value things that work in the same POS network). the digital
signature then flows with the standard 8583 message.
iso group responsible for 8583 has already approved the standard for
the 8583 field to carry the x9.59 data.
when the issuing/client financial institution eventually gets the 8583
financial transaction ... they can directly verify the integrity of
the financial transaction with the x9.59 digital signature.
an abstract of that is at
https://www.garlic.com/~lynn/8583flow.htm
a reference to the NACHA pilot for debit/atm network can be found by
following the pointers at (even tho it was a nacha sponsored event
... it was with debit/atm network which is an ISO 8583 operation, as
opposed to electronic ACH message format):.
https://www.garlic.com/~lynn/x959.html#aads
there has been some work by the people that worked on the FSTC
electronic check in ACH to perform the same mapping from X9.59 to ACH
electronic messages .... getting the same end-to-end intetrity for ACH
electronic transactions (checks) at for 8583 networks (credit, debit,
stored value, etc).
Note all of this work is for electronic retail transaction providing
end-to-end integrity of security of the actual financial transaction
(not some other end-to-end transaction that is different than the
actual financial transaction). It was designed to be usable for all
electronic retail transactions in all environments.
note the current predominate WEB infrastructure send credit card
information from the client to the merchant. The WEB merchant takes
that in transforms it directly into a 8583-like message that is pumped
into the credit card network (via the merchants acquiring processor
interface). The original WEB merchant implementations effectively
emulated the same process that the electronic point-of-sale terminal
used to interface into the merchant's acquiring processor
interface. misc. refs:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
The x9.59 specifies the data elements and the format of a signed message
... that the client/customer needs to send to the merchant (whether it is a
POS terminal or a client internet machine).
The reference
https://www.garlic.com/~lynn/8583flow.htm
describes how the merchant processing (web or POS) takes the
additional x9.59 information and includes it with the standard 8583
transaction that the merchant is already generating for the financial
transaction.
what is not described is how the hundreds of thousands of web
merchants and possibly tens of millions of POS terminals already
work. what is described is the additional change to how it currently
works to support x9.59 end-to-end authentication and security.
X9.59 wasn't attempting to create a brand new process and
infrastructure. X9A10 group was attempting to define a ubiquituous
standard for electronic retail payments (regardless of the kind) and
the minimum changes necessary to all the existing electronic retail
payments to add end-to-end integrity and security.
note that X9.59 standard also doesn't specify the actual client-to-CFI
process .... in part, because X9.59 was being targeted for every
retail electronic payment (not just internet & not just credit). A
lot of work was put into X9.59 standard so that it could be
incorporated into every existing retail payment ... regardless of
internet, credit, debit, point-of-sale, stored-value, etc. and provide
end-to-end security and integrity for that financial transaction .. as
opposed to creating some other transaction which might or might not be
in anyway related to the actual transaction.
Proposal: A replacement for 3D Secure
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/27/2002 03:01 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>
Subject: Re: Proposal: A replacement for 3D Secure
<resend, possibly mailer problem, getting bounced error response to
fstc.org listserve>
if we were worried about not doing something that wasn't already supported
... we probably wouldn't have worked on the initial implementation
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
note that today there are already a number of pretty transparent proxy
operators for virtual POS terminals (aka in effect most current web
e-commerce credit card transactions are run thru what is essentially a
virtual point-of-sale terminal to generate an acceptable 8583
financial transaction message for the merchant's acquiring
processor). Instead of the merchant running the actual the virtual POS
terminals (or virtual cash registers) .... that part of the operation
is outsourced to a 3rd party. Some number of these operations have
provided client password based operation that filled in all the
relavent credit-card information on behalf of the client/customer.
This 3rd party proxies are in use today. The mechant passes the
customer off to the 3rd party "proxy" and they do their thing
.... including any password oriented stuff that automatically injects
the appropriate credit card information into the 8583 message before
sending it off to the merchant's acquiring processor.
Applying the proxy approach discussed in PKIX ... extended it to
public key ... and x9.59 ... there is nothing preventing any of these
3rd party "proxies" from creating a public/private key pair for each
client .... and performing a x9.59 digital signature and including it
in the 8583 message that eventually makes it way to the customer's
(issuing) financial institution. The client would not see any
difference to what they see today using password authenticated 8583
transaction (the 3rd party proxy would just be adding all this
additional stuff to it). In fact, the client wouldn't even have to
know that the 3rd party proxy has injected x9.59 digital signature
information into every 8583 transaction. It is relatively simple and
straight foward enhancements to the existing 3rd party proxy virtual
POS terminal operations (and the extension would be totally
transparent to the client).
Now, functionally I don't see any difference between that proxy
implementation and some of the bifurcated proxy proposals (having two
different proxies .... one responsible for client authentication that
generates the actual 8583 financial transactions .... and a totally
different proxy that signs a totally different transaction and tries
to figure out how to route it to the client's financial institution
... as well as somehow connect it to the real financial
transaction). Having it all in a single 3rd party process would appear
to be quite a bit more secure and less failure prone as well as
KISS. The difference is that while it might be more secure, less
failure prone and more KISS ... somebody might be more likely to ask
why do it at all (as opposed to doing the same thing in a much more
complex, complicated and failure prone operation).
misc. postings in the PKIX proxy thread:
https://www.garlic.com/~lynn/aadsm11.htm#19 IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#25 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#26 Proxy PKI
https://www.garlic.com/~lynn/aadsm11.htm#27 Proxy PKI
anders.rundgren@xxxxxxxx 5/27/2002 1:45 pm wrote:
Lynn,
Although security-wise probably perfect, such a solution is
incompatible with current COTS (Commercial Of-The-Shelf)
software, while neither 3D Secure, nor its proposed
replacement, demands anything new on the client side.
If security alone was the "perimeter for success" maybe
X9.59 would be the only game in town, but simple
deployment is probably the #1 parameter. That's the reason
why smart-cards are said to be "coming strong next year".
I just wonder what calender these guys are using :-)
Regarding the idea that financial security must consist of an
unbroken signature all the way from the client to the end-
destination (which is?), I remain unconvinced that this ever
will be the dominant way to do things for a number of reasons,
where the most important one is, that it typically requires key-
generation and/or key-distribution for every kind of account etc.
a customer may have the right to use which seems very
impractical.
A two-step PKI (client-to-FI, FI-to-Merchant) is more flexible
as the client-side PKI may be a single ID-card-like credential
activating any number of external Server-PKI resources at
any number of TTPs (FIs, Employers etc).
Server-PKI (proxy-PKI) has recently been discussed in the
IETF-PKIX list, and I note with pleasure that the resistance is
gradually going down. Three years ago, I was [very] alone in
that list advocating for such "heretic" uses of PKI. Nowadays
even esteemed cryptographers like Peter Guttman and Phillip
Hallam-Baker (SAML architect), seem to be "hanging out with
the bad guys".
cheers,
Anders Rundgren
Proposal: A replacement for 3D Secure
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/28/2002 08:08 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments a <internet-payments@xxxxxxxx>
Subject: Re: Proposal: A replacement for 3D Secure
as mentioned in previous note ... x9.59 was designed to be used to
authenticated the actual financial transaction ... not some other
financial transaction. with regard to 8583 (credit, debit, atm, etc
transactions) a mapping was provided between what the client provided
the authentication for and the actual transaction. Some work was also
done mapping between x9.59 and other transaction message formats (like
ACH ... checks).
with regard to proxies ... the previous note mentioned that there are
already 8583 proxies operating effectively "virtual" POS terminals
(i.e. web processing that simulates the message generation that
occurs in point-of-sale terminals before passing it off to the
merchant's acquiring processing). some of these existing proxies also
provide a customer/client password service .... allowing the customer
to provide userid/password (or possibly cookie/password) and all the
relevant 8583 fields that need be supplied by the customer
(PAN/account#, address, name, etc) is automatically filled in.
For those 3rd party proxies that already provide such a service
... the previous note observed that these existing 3rd party proxies
could generate public/private keys on behalf of their
clients/customers and include digital signatures in the actual
transaction (even x9.59 comformant digital signatures) with no
requirement for any additional effort or knowledge of their customers.
A possibly side issue is while other documents may not mention 8583
... if you are doing a credit card transaction ... the actual
transaction is 8583 regardless of what else you might do. Now if you
want to authenticate the actual transaction ... then if it is a 8583
transaction ... you have to do something about providing
authentication for the transaction (whether you bother to mention that
it is 8583 or not). Furthermore, if something is provided that claims
that it is somehow related to the financial transaction ... and it
isn't done by authenticating the actual transaction (whether it is
called 8583 or not) ... but is doing some totally different
authentication ... then it isn't end-to-end security in the
traditional security sense of the term (that was also mentioned
somewhere in the PKIX thread).
previous post:
https://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D Secure
anders.rundgren@xxxxxxxx on 5/28/2002 12:47 am wrote:
Lynn,
I think we are talking about rather different things, including
using different "languages" :-)
But I did not see a trace of any web-based client-solutions on the
X9-web-link that your X9-college Tom pointed to.
Because I'm mainly focusing on the client-solution for web-based
transactions. Particularly as I feel this is the biggest problem.
Therefore a "zero-client" solution seems like a necessity.
Zero-client (using my definition), is to not require any hardware or
software beyond what the clients already need for connecting to their
Internet-banks. Such solutions are currently all over the map,
spanning from userid/passwords to full-fledged PKI- solutions using
smart-cards and digital signatures. I don't intend to even touch
this part, as this would be like begging for a major disaster. Like
SET 1.0...
Regarding the transaction from the CFI=>Merchant=>Acquirer, I'm open
for suggestions as this is not my "territory". So if X9.59 is
compatible with current schemes it should fit right in. Please feel
free to suggest how X9.59 could replace the current 3D Secure
authenticated payer message and what the pros and cons (there must be
such as well), would be with respect to the existing payment
structure(s) which you are much more acquainted with than I am.
I noted though that the 3D Secure specification does not even mention
8583-transactions which indicates that there are some problems in this
end as well which may call for switching/proxying etc.
cheers,
Anders
ALARMED ... Only Mostly Dead ... RIP PKI
From: Lynn Wheeler
Date: 05/28/2002 09:22 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: ALARMED ... Only Mostly Dead ... RIP PKI
http://www2.cio.com/research/security/edit/a05232002.html
ALARMED ... Only Mostly Dead ... RIP PKI
Refed: **, - **, - **
From: Lynn Wheeler
Date: 05/28/2002 05:15 PM
To: Chuck Wade <chuck@xxxxxxxx>
cc: Internet Payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI
I was on a PKI panel at NISSC conference a couple years ago. The first
three speakers were from the traditional PKI vendors and their basic
message was something to the effect that .... everybody has heard all
the stories about how really hard PKIs are ... well, I'm here to tell
you that it is much, much easier than you've heard.
I then gave a AADS talk
Then the last speaker made some opening statement to the effect that
.... they were responsible for the oldest and largest PKI in
existance (some DoD thing) and everybody has heard all the stories
about how really hard PKIs are ... will, I'm here to tell you that it
is much, much harder than you've heard.
Now a couple years before that, my wife and I had been doing this
stuff associated with electronic commerce.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
and we had a couple decades experience between us with data processing
that provided industrial strength service operations. So one of the
things that we did as part of this SSL thingy was go around and
perform due diligence on the major PKI operations and talk about what
it means to operate an industrial strength service. I think w/o
exception the response was that they were starting to find that out
... that they had gone into it with the idea that it was somehow a
computer or cryptographic technology thing and were finding out that
the computer stuff and the crypto stuff represented possible 5 percent
of what they needed to do.
The AADS stuff isn't so much about certificates or no certificates
... it is about industrial strength service operations are really hard
to do right ... and incorporating public key into an existing service
operation may have significant upfront effort just to get off the
ground (aka AADS) compared to deploying a simple, stand-alone CA
server (aka CADS) ... but AADS then is able to take advantage of
significant investment in existing infrastructures for providing
industrial strength data processing service ... and opposed to growing
it from scratch for a brand-new operation.
Simple CA servers are pretty straight forward ... comparable to say
any other departmental server effort. It is making the transition from
simple departmental server stuff into large scale industrial strength
data processing that lots of other issues start to raise their head
(the transition from 10-20 person departmental service to a several
hundred thousand person enterprise service is not necessarily a
straight forward or even linear scale-up).
chuck@xxxxxxxx on 5/28/2002 4:07 pm wrote:
lynn.wheeler@xxxxxxxx wrote:
> http://www2.cio.com/research/security/edit/a05232002.html
Lynn,
Thanks for passing along the reference to the ALARMED editorial
in CIO by Scott Berinato. It manages to come a bit closer to the
truth than have many of the other pieces written on the death of PKI.
I would add a couple of observations of my own. First, the
financial industry itself is largely responsible for escalating
the requirements of PKI systems and services to truly absurd
levels. Building massive infrastructure with extreme security
appealed to the investment community that was happy to finance
the PKI endeavors of multiple startups and spinoffs. After all,
if the major banks were all saying they needed this stuff, then
it must be a good investment to back the folks building these PKI
palaces and Maginot Line defenses.
It is interesting to reflect on the original concepts for PKI
systems (developed long before the term "PKI" came into use).
These concepts envisioned simple workstation systems with addon
security hardware for key protection that would operate as
Certification Authorities (CAs) out where the credentials were
being issued. The US DoD secure messaging systems actually
deployed such CAs. The early Netscape server products also
included simple CA software solutions, still used by many today.
Microsoft offers similar CA solutions as well.
What is unfortunate in the current dialogue is how few people
discuss the successes of PKI in their rush to be among the first
to stamp on the grave of PKI. In reality, PKI is widely used
today, and not just for SSL server side authentication and key
exchange. Many organizations effectively use secure email
solutions (e.g., S/MIME) with standard X.509 certs (I regularly
conduct sensitive client business using S/MIME and certs I
conveniently acquired from Thawte's service). Lotus Notes is very
popular with many corporations, and is based on public key
certificates, although only recently has Notes begun to use
standard certs instead of their earlier proprietary constructs.
But more importantly, and perhaps more to the point, the core
concept of digitally signing a public key remains central to many
applications of public key cryptography. Furhtermore, public key
crypto remains a useful security technology that can be applied
to a wide range of problems. Whether or not a signed document
containing a public key is called a certificate, or something
else, is mostly a matter of terminology and choice of standards.
Lynn, before you jump in with any claims about the virtues of
AADS, I will acknowledge that certificate-like objects are not
always required, especially when the appropriate keys (private
and public) can be selected through some other context, such as
the name or userid or account number of one of the parties.
Hopefully, you will also agree that there are also situations
where parties do not know "a priori" the public keys of the other
parties, and some sort of mechanism is required to exchange and
confirm the authenticity of the public keys.
So, as Mr. Berinato's editorial points out:
> "As complex as Public Key Infrastructure is,
> the theory is sound."
> "So while the concept behind PKI was appealing,
> everything else about it was shoddy."
Both are accurate observations, although I would tend to refer to
commercial PKI solutions as more "overblown and gilded" than
"shoddy," although I do know of some examples of shoddy PKI systems.
My conclusion is that PKI has come to mean a "poorly chosen path"
for achieving effective deployment of security measures based on
public key cryptography. The PKI path has favored entrenched
interests and "big iron" solutions. This path has also confused
many about what the ultimate destination should be. What needs to
be recognized--and more broadly communicated--is that there are
other paths to achieving effective use of public key crypto as a
set of mechanisms for building secure applications. We need to
stop focusing on the wrongness of the PKI path, and move the
debate to more constructive dialogues about what the right path
(or paths) should be. To this extent, I appreciate the
suggestions that Anders has been putting forward because I
believe he's talking about possible new paths, not bemoaning how
we got here.
Just some thoughts...
--
...Chuck Wade
Consultant, Internet Security and Financial Services
+1 508 625-1137 Office Phone/Voice Mail
+1 309 422-9871 Fax Service
ALARMED ... Only Mostly Dead ... RIP PKI
From: Lynn Wheeler
Date: 05/29/2002 10:21 AM
To: Chuck Wade <chuck@xxxxxxxx>
cc: Internet Payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI
I believe the reason that certificates were "invented" was to provide a
basis for trust between parties that had no prior relationship in an
offline environment .... aka the letters of credit analogy from the days
of sailing ships and before telephone & telegraph. These were the days of
offline email when you would connect to the local POP and download your
email and then hang-up. It was then necessary to authenticate the sender of
email in situation where you had no prior knowledge/relationship with the
sender.
note that early on we coined the term certificate manufacturing to
distinguish the SSL environment from PKI. straight certificate
manufacturing operation was somewhat simpler than a real service
operation.
chuck@xxxxxxxx on 5/29/2002 8:49 am wrote:
The reason that certificates were "invented" was that new
applications for public key cryptography emerged where "a priori"
knowledge of public keys could not be assumed. Secure email is a
classic example of an application where there is a need to
exchange public keys between parties where there is no prior
knowledge of the other party's keys. SSL web sessions represents
another such application as do some payment applications (e.g.,
the FSTC eCheck initiative). I should also acknowledge that
different approaches for creating public key certificate-like
structures do exist, along with different trust models.
The danger in continuing to flog the "dead" PKI horse is that it
further deflects attention away from the more relevant problems
of inadequate commercial solutions for any of the critical
security problems confronted by individuals, businesses and
governments. The ongoing debates surrounding authentication
services serves to sharply illustrate just how little progress
has been made. Furthermore, the current climate continues to
promote a contentious atmosphere with bitter competitive
rivalries and conflicting priorities undermining many efforts to
make forward progress.
To my earlier point, our current definition of PKI should be
viewed more as a path that is no longer going anywhere useful.
The options are to:
backtrack to some earlier stage of development and start anew,
somehow switch onto another path that shows greater promise,
or pick a new direction and take advantage of what progress has
already been achieved.
Each of these options has its advocates, but I'll admit that I
tend to favor the latter option on pragmatic grounds.
What is even more important, however, is to focus on the critical
needs for effective security measures that can be widely deployed
and adopted, and that can evolve rapidly to confront an array of
new threats.
Let's be honest, the security of payment transactions today is
far worse than it was a decade ago. This is due to the failure to
improve security measures for payment transactions, while broader
information dissemination and new technologies have enabled an
array of new threats with corresponding risks. Put differently,
the "moral hazards" embedded in our current payments
infrastructure are of historic proportions, and the trends are
not looking healthy right now.
Therefore, debating the "death of PKI" is a distraction that
deflects attention from the true problems. It is high time we
focus on better ways to mitigate the security risks associated
with both legacy and new payment transaction services. The need
for public key infrastructure to support new security measures
can then be defined rationally based on real requirements instead
of impossible or conflicting objectives. My personal suspicion is
that the eventual solutions will have aspects of many of the
current models, but without so much baggage.
Does this make sense?
Regards...
--
...Chuck Wade
Consultant, Internet Security and Financial Services
+1 508 625-1137 Office Phone/Voice Mail
+1 309 422-9871 Fax Service
ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
Refed: **, - **, - **
From: Lynn Wheeler
Date: 05/29/2002 04:17 PM
To: Chuck Wade <chuck@xxxxxxxx>
cc: Internet Payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
now the original assumptions for the invention of certificates were 1) no
prior relationship and 2) offline (aka the letter of credit credential from
sailing ship days).
now in the financial standards body there is a standards effort called
certificate credential (x9 sixty something or other) ... in part because of
the extremely onerous payload overhead that a typical x.509 certficate
represents to all of the payment networks
note however in the effort for certificate size reduction one of the
techniques is recognizing that the original assumptions for the invention
of certificates don't usually apply to modern day payment transactions ....
typical there is a prior business relationship between a financial
institution and there account holder and for electronic transactions (that
might involve a digital signature) the transactions are mostly online.
recognizing this, one of the techniques in the certificate compression
activity is that some fields can be eliminated (from a typical x.509
certificate) because there are prior business relationships between a
financial institution and their customer. The analogy might be tthe letter
of credit credential design to introduce a customer of the bank of england
(?) to the president of some bank in south america (sailing ship days
before the invention of telegraphy and telephone). So we have a customer of
the bank of england that wants to do payment transaction with the bank of
england ... he goes to the president of the bank of england and requests a
letter of credit credential introducting himself (the customer) to the
president of the bank of england. The president of the bank of england
writes such a letter of credit credential for the customer that will
introduce the customer to the president of the bank of england and
gives it to the customer. The customer then turns around and gives it back
to the president of the bank of england (i.e. the president of the bank of
england introducing the customer to the president of the bank of england).
so the x9 sixty something or another recognizes that there can be some
things that aren't really necessary in a payment certificate .... compared
to the x.509 original certificates targeted for offline introduction
between two entities that have had no prior business relationship. well,
being aggresive in that effort for a situation where the customer is the
customer of the bank and the payment transaction is online (effectively
negating the original assumptions for the invention of certificates) ....
it is possible to compress/eliminate all fields in a typical x.509
certificates so the certificate now has zero fields.
the question now is what is the size of a x.509 certificate that has
all fields eliminated? which would represent an extremely aggresive
application of compression to the extremely onerous payload that a
typical x.509 certificate reprsents to the payment netwoirks.
ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/29/2002 08:18 PM
To: Chuck Wade <chuck@xxxxxxxx>
cc: Internet Payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
that should have been certificate compression ... not certificate
credential (x9 sixty something or another)
to handle the extremly onerous payload penalty that a standard x.509
certificate size represents in all the traditional payment networks.
now as to the SSL stuff ... the long version is at:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
a much shorter version is that certificates represent trust ... nominally
between two parties that otherwise have no prior relationship in an offline
environment (or at least an environment where there aren't online resources
that can be relied upon).
so SSL certificate is basically to check that the domain name in the
entered URL matches the domain name in the certificate (can I trust that
i'm actually talking to the id adress that i believe i'm talking to). the
justifcation for all this is there is some question regarding the integrity
of the domain name infrastructure that provides the domain name to
ip-address translation for all internet operations .... so we'll use a
trusted certificate to provide a redundant check as to the integrity of the
domain name infrastructure provided information. So how does the CAs check
the validity when somebody applies for a SSL certificate? Well, CAs or
certification authorities ... nominally go to the authoritative agency for
the information to validate accuracy. So who is the authorative agency(s)
for domain names that certification authorities check with regard to
SSL certificates? well it turns out that they have to check with the domain
name infrastructure (because the domain name infrastructure is the
authoritative agency for domain names) ... this is the very same domain
name infrastructure that is the subject of integrity issues giving rise to
the requirement for SSL certificates in the first place. The long & short
of it is that there are some specific suggestions about how to improve the
integrity of the domain name infrastructure .... so that certification
authorities can trust the information that they validate as part of going
about issuing trusted SSL domain name certificates ... however, the
improvement of the integrity of the domain name infrastructure (for the
purposes of certification authorities) also can eliminate the original
justification for having SSL domain name certificates in the first place.
ALARMED ... Only Mostly Dead ... RIP PKI
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 05/30/2002 04:49 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>,
sberinato@xxxxxxxx, sscalet@xxxxxxxx, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI
as noted in previous note ... we had coined the term certificate
manufacturing to distinquish SSL environment from PKI early on when
we were working with this small client/server startup in menlo park
that wanted to do payments in conjunction with this thing they had
developed called SSL.
other related discussions regarding SSL
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
anders.rundreg@xxxxxxxx on 5/30/2002 1:40 am wrote:
I think I'm less alarmed. As noted by Chuck Wade, PKI is used by
hundreds of millions of users in the form of HTTPS.
Regarding client-side PKI one of the biggest problem is that there is
no consensus what a certificate is supposed to vouch for.
This is my year 2005-2008 "prophecy" for what it is worth:
Commercial client-side PKI will consist of "ID-card" like TTP- issued
certficates. The CAs will consist of 2-5 networks of banks. The
reason that the banks will take this market is that they must anyway
have a registered relation with their clients which means that the
RA-part is "for free". No one else can match this!
Now, to another interesting part:
These certificates will neither vouch for the individual as being
employed somewhere, nor being authorized to do something particular,
just telling that this is John Doe with customer ID 4545445 isued by
MegaBank of Galaxy Trust Network.
Why this: Beacuse such a certficate can be used for any purpose
in the communication with an individual's own trusted parties.
Trusted parties means your bank, your employers, some authorities.
The reason to use ID-card-like PKI's with untrusted parties like
Internet-merchants seems like an unlikely idea for many reasons.
This is BTW also based on the idea that the proxy-way of PKI-ing
(like 3D secure) will be the dominating way to do things like
credit-card payments and B2B-purchasing.
And who is paying: The customer as they already do for passports,
driver licenses etc. $10-25/Year is a rough estimation.
And where will we keep it: In our PDA's and mobil phones. The
card-makers have screwed up things by making properietary solutions
which means that they are "toasted" as far as I can see.
What will never happen on a grand scale is: Every company issues
certficates to their employees that in turn use these for interaction
with external business parties. They will always interact through
a proxy (or "business system" as it is usually known as). As in:
https://web.archive.org/web/*/http://www.x-obi.com/OBI400/GEA-B2B-PKI.ppt
cheers,
Anders
ALARMED ... Only Mostly Dead ... RIP PKI ... part II
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/30/2002 05:31 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>,
sberinato@xxxxxxxx, sscalet@xxxxxxxx, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI ... part II
as an aside, there was booth at cardtech/securetech a couple weeks ago in
new orleans for a hardware token that just did ecdsa (fips186-2) digital
signatures w/o any certificates..
earlier this week source-forge accepted the statement for package of server
side fips186-2 signature authentications software and the package should
be on source forge shortly
http://www.sourceforge.net/
a possible issue for financial institutions, once they have "already done
the RA-part for free" ... would they then issue certificates that have
design point of both 1) offline environment and 2) for people with no prior
business relationship .... or would they acknowledge that the world has
significantly moved towards an online, real-time environment (like they
have for payment transactions) and any significant need for the old offline
design point that certificates were invented for has possibly passed on by.
anders.rundgren@xxxxxxxx on 5/30/2002 1:40 am wrote:
I think I'm less alarmed. As noted by Chuck Wade, PKI is used by
hundreds of millions of users in the form of HTTPS.
Regarding client-side PKI one of the biggest problem is that there is
no consensus what a certificate is supposed to vouch for.
This is my year 2005-2008 "prophecy" for what it is worth:
Commercial client-side PKI will consist of "ID-card" like TTP-
issued certficates. The CAs will consist of 2-5 networks of banks.
The reason that the banks will take this market is that they must
anyway have a registered relation with their clients which means that
the RA-part is "for free". No one else can match this!
Now, to another interesting part:
These certificates will neither vouch for the individual as being
employed somewhere, nor being authorized to do something particular,
just telling that this is John Doe with customer ID 4545445 isued by
MegaBank of Galaxy Trust Network.
Why this: Beacuse such a certficate can be used for any purpose
in the communication with an individual's own trusted parties.
Trusted parties means your bank, your employers, some authorities.
The reason to use ID-card-like PKI's with untrusted parties like
Internet-merchants seems like an unlikely idea for many reasons.
This is BTW also based on the idea that the proxy-way of PKI-ing
(like 3D secure) will be the dominating way to do things like
credit-card payments and B2B-purchasing.
And who is paying: The customer as they already do for passports,
driver licenses etc. $10-25/Year is a rough estimation.
And where will we keep it: In our PDA's and mobil phones. The
card-makers have screwed up things by making properietary solutions
which means that they are "toasted" as far as I can see.
What will never happen on a grand scale is: Every company issues
certficates to their employees that in turn use these for interaction
with external business parties. They will always interact through
a proxy (or "business system" as it is usually known as). As in:
http://www.x-obi.com/OBI400/GEA-B2B-PKI.ppt
cheers,
Anders
ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/30/2002 07:53 PM
To: Chuck Wade <chuck@xxxxxxxx>
cc: Internet Payments <internet-payments@xxxxxxxx>
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
there are two parts of certificate design point (not just one)
1) no prior relationship (i.e. except in the introductory stage, not
applicable for financial infrastructure)
2) offline (not applicable in the online payment infrastructure)
all things considered somebody that is being paid would prefer an online,
realtime notification that the financial institution says that the money is
available and is being transferred (i.e. if they get their money they don't
actually need to know who you are .... which is the EU directive that
point-of-sale electronic financial transactions are as anonymous as case).
it is only when things regress to pre-1970 technology into an offline world
that a poor 2nd choice is to know who you are ... as opposed do i already
have the money.
another payment scenario from pre-1970.. are corporate checks that had
signing limits printed on the checks (somewhat analogious to certificates
of a particular kind). they discovered that fraud was happening by people
signing 200 $5000 checks for $1m ... aka no real time aggregation. The
transition was made from signing check limits to real-time aggregation.
given an online infrastructure .... is it better to have transaction built
around stale, static data ... or transaction built around real-time
aggregation information.
The design point of "trusted" stale, static data (aka some sort of
credential or certificate) in an offline system is better than having no
information aka that was the original invention justification for
certificates .... not having an online system to get real-time, up-to-date
transaction aggregation information (if you are in a pre-1970 technology
situation ... with offline payment transaction ... then some sort of
certificate is better than not having anything). However, given that there
possibly is the availability of a post-1970 online technology ... that it
would appear to be a better choice to go with an online transaction as
opposed to an offline transaction paradigm.
Now some of the past payment related certificates have been in the 1k to 4k
byte range. There is significant portion of payment transaction that
currently operate with 80-100 bytes. The x9.59 mapping to ISO 85838
networks has one the order of 80 byte payload increase ... 42byte ecdsa,
fips186-2 signature plus misc. other information for increased integrity. I
believe that some of the x9 sixty-something certificate compression is
talking about a simple straight-foward something on the order of 300 bytes
for a ecc (163-bit) public key and a 42 byte ecdsa signature. note however,
that the whole design point for such a certificate is to be able to
authenticate an offline transaction ... since the certificate is redundant
and superfluous in online transactions processed by the customer's
financial institution. There is some push back on the unique information in
the x9.59 addenda since it almost doubles the size of existing payment
transaction. The pushback is even worse when considering an optimized,
compressed, 300-byte ecc certificate that is totally redundant and
superfluous and servces no valid business purpose.
Note however, that if such a certificate were to contain any identification
information and it was viewed by any but the customer's financial
institution then it would be in violation of the EU's anonymous directive.
Now, the financial institution doesn't need the certificate ... since it
already has all the information. The merchant doesn't need know anything
from the certificate if there is a realtime online transaction that gives a
real-time commitment from the financial institution that 1) it is a valid
transaction from 2) a valid customer account, 3) there is sufficient funds,
and 4) the bank is transferring the funds.
Part of this is that it is post-1970, there is significant world-wide
coverage for doing online transaction, that being able to do online,
real-time, payment authorization taken into account real-time account
transaction aggregated information .... is of higher quality than an
offline transaction with stale, static information possibly year or more
old.
with regard to legacy systems (including stove-pipe legacy systems), i made
the statement that there is a much larger upfront cost to integrate public
key support into existing production system ... as compared to the upfront
cost to deploy a brand new server with new operation (especially if it is a
simple SSL-like certificate manufacturing ... as opposed to full-blown
PKI).
The problems that have cropped up in financial consumer certificate issuing
(whether PKI or simple certificate issuing) ... is that there is the issue
of keeping a customer database. that customer database then has to
eventually have all the customer activity support as the "real" production
customer account database operation. The presentation made at NISSC
(previously mentioned) calculated that the cross-over point for financial
institutions between the upfront cost reduction of doing a separate PKI
operation ... as opposed to modifying the stove-pipe legacy stuff for
public key authentication was somewhere around 5 percent of the account
base. If financial infrastructure was looking at supporting less then five
percent of its customer base with public key authentication ... then a
separate PKI "stove-pipe" was probably cheaper. If the financial
infrastructure was looking at supporting public key authentication for more
than about five percent of its customer base ... then it was probably
cheaper to modify the existing stove-pipes (than it was to effectively
create a new and separate stove-pipe for PKI).
my statement has always been that a trusted stale, static
certificate/credential is always better than nothing when you are in an
offline world and don't have access to real-time, online information.
However, for almost anything of importance or value ... given the
opportunity of doing either 1) a real-time online transaction or 2) doing a
offline, delayed transaction based on stale, static certificate ... which
would one choose.
Given a infrastructure that is in general moving towards online, real-time
.... the multiple legacy stove-pipe situation would be aggravated with yet
another (PKI) stove-pipe (in other than very early technology exploratory
pilot stages)
Given some infrastructure that is really an offline environment ... then it
is obvious that a trusted, stale, static credential/certificate is better
than nothing at all. The statement that certificates are redundant and
superfluous in an online, realtime payment transaction infrastructures is
in no intended to imply that they are totally useless and/or don't have
application. They were specifically invented for offline environment for
parties that have had no prior relationship/knowledge.
Something as an aside, the online payment infrastructure ... is in effect
an online certification authority paradigm ... with realtime online
ransactions as opposed to trusted stale, static credential/certificate
offline paradigm. It turns out that the certificate issuing certification
authorities actually make extensive use of this realtime online feature for
some number of consumer/client certificates they issue. They effectively
take a credit card in payment for the credential they issue ... and for the
basic credential type with name and address use the name/address
verification option of the realtime credit card transaction as the means of
checking the name and address. There are some number of other web-based
"certification" sites (some doing realtime transactions in lieu of stale,
static credentials and others that issue a form of short-lived credentials
... possibly analogous to kerberos tokens) that also rely on the
name/address verification option of the realtime credit card transaction as
the means of checking name and address.
chuck@xxxxxxxx on 5/30/2002 8:25 am wrote:
Lynn,
You do put an interesting interpretation on things.
A few points worth noting:
(1) Letters of credit are very much alive, today, having
survived the invention of the telegraph, the telephone, and, so
far, the invention of the Internet. They are in regular use for
lots of global commerce activities. There are even electronic
versions of letters of credit. Suffice it to say that there is
still value in being able to extend one's business reputation
(credit) beyond one's normal domain of operations.
(2) To put things in perspective, the primary contributors to
the "onerous payload" in X.509 certificates are the public keys
themselves. Next are the signature blocks of the issuers. Basic
X.509 certificates do little more than provide the name of the
subject of the certificate, the name of the issuer, and some
basic management information, such as the starting and ending
dates for when the cert is valid. Plastic mag-stripe credit cards
actually carry a lot more information than do basic X.509 certs
(although public keys are longer than credit card numbers). True,
there are lots of optional fields and extensions in the X.509
standards, but even when these are used, they generally don't add
that much bulk (unless someone really does stick the entire
certificate practice statement into the cert). [Please, before
you respond with a list of your favorite stats on cert size and
hyperlinks to your voluminous archives, read on and recognize
that none of this really matters until we better understand what
we're trying to accomplish.]
(3) While it is true that you don't need a cert in the case
where the issuer is the only party that will rely on the cert,
this is not the typical case in most business situations. Even
banks tend to have lots of stovepipe operations that have no good
internal means for sharing information about customers and their
reputations. Many other businesses are also comprised of multiple
stovepipes. There may also be good reasons that the "Bank of
England" (to cite your example) might issue a letter of credit to
a customer based in England to help facilitate their opening of
an account at the Bank of England branch in some other part of
the world. If all the legacy systems in place today could
effectively exchange information in a trustable fashion, then
maybe such "inefficiencies" would not be required--but they don't!
It might also be worth noting that payments are between _payers_
and _payees_. Goverment Treasuries, banks and payment service
providers merely facilitate the payment transactions and provide
some "insurance" for a subset of the payment transactional risks.
The key point is that payer-payee transactions are highly
distributed in nature, and often between parties that have little
or no transactional history with each other. Just a suggestion,
but maybe we need to focus a bit more on how to facilitate
payer-payee interactions and give payers and payees the tools
they need to manage the very real risks they confront with every
payment transaction.
The reason I provided some commentary on the editorial by Scott
Berinato was that I'd like to see the industry dialogue move away
from arguments about the machinery, and to more on-topic
discussions of what it will take to create viable payment
applications that can be conducted safely over the Internet. With
a better understanding of user needs, system requirements, and
appropriate architectures for new payment applications, perhaps
we will then have the insight to intelligently evaluate what
sorts of machinery will actually serve our purposes.
As I've already emphasized, the PKI approach is on the wrong
path. But, if you'll forgive me for saying so, I contend that
your approach is also not showing a great deal of promise these
days. To be honest, only a narrow set of applications is served
by a model where the issuer of public key credentials is also the
only relying party. This might work for some highly centralized
application models with rigid constraints on the relationships
between the players. It is, perhaps, even a good model for
extending some legacy systems, especially where closed protocols
and networks are used.
Personally, I think it is a good idea to look at how new payment
applications can leverage, and even extend, legacy payments
infrastructure. On the other hand, I think it would be a mistake
to continue the practice of stamping out new payment applications
and innovative approaches for the sake of protecting existing
payment system franchises that are protected by closed systems
designs and technological constraints from the 70s and 80s. But
that's just one man's opinion.
Regards...
--
...Chuck Wade
Consultant, Internet Security and Financial Services
+1 508 625-1137 Office Phone/Voice Mail
+1 309 422-9871 Fax Service
ALARMED ... Only Mostly Dead ... RIP PKI ... part II
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
... note misc spellchecking, formating, finger fumble cleanups
From: Lynn Wheeler
Date: 05/31/2002 08:35 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "internet-payments" <internet-payments@xxxxxxxx>,
sberinato@xxxxxxxx, sscalet@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI ... part II
of course it is possible to use stale, static credential/certificates
for both online and offline transctions. The point is that stale,
static credential/certificates are a design point for offline
transactions between parties that.have no previous
knowledge/relationship ... being better than the alternative
... nothing. (payment infraustructure is used to having risk
management built around real-time aggregated information , why would
they revert to an offline paradigm model for payments with stale,
static infromation ... it is like dropping back into the dark ages).
Given any transaction involving something of importance or value
... given two equally available paradigm alternatives: online and
offline ... why would anybody choose to have stale, static information
when they could have real-time, uptodate, aggregated information
(current account balance and actual funds available for payment
transaction)? The choice of an offline paradigm with stale, static
credentials/certificates presumbly would only be made when there was
no choice for an online paradigm alternative. It is like old fashion
business signing limit checks for fraud management ... it is a stale,
static credential ... it is better than no limit at all ... but not as
good as real-time, aggregated information for a payment transaction
giving actual funds available for current transaction.
Yes a financial institution could sell a consumer a stale, static
certificate so that customer could use it for offline transactions
with somebody that they previously didn't know or previously didn't
have a business relationship with .... or they might even be given a
free certificate at some public-key RA-registration event. However,
given an infrastructure that is partially already online,
realtime, would they want to throw away the current online paradigm
and revert to offline?
There are portions of the infrastructure that is not already
online, realtime ... but mainly because it is non-electronic. The
question is if the remaining portions of the payment infrastructure
were to start migrating to electronic ... what would be the portions
of those remaining non-electronic payment infrastructures that would
migrate to electronic but offline vis-a-vis electronic and online. The
stale, static credential is a solution for the electronic and offline
design point. They are redundant and superfluous in the scenario for
electronic, online, real-time transaction that involves aggregated
information (aka current funds available or account balance, i.e. an
account balance represents aggregated information in the sense it is
the summary of all the account deposits minus all the account debits
that can be occuring in real time)
Note however, that more and more of the world seems to be moving
rapidly to electronic and online (especially with the aggresive
wireless activity) . stale, static credentials are redundant and
superfluous in the online, realtime world between parties that have previous
relationship (like financial institutions and their customers).
At least in a couple of cases, the stale, static credentials appeared
to have actually resulted in an offline payment solution because it
didn't appear that it was reasonable to carry digitally authenticated
transaction on the online payment network because of the onerous
payload represented by the stale, static credentials themselves. It
was then possible to show that the credentials were just a stale,
static read-only copy of a subset of the information on file in the
account record. It then became trivially obvious that returning a copy
of stale, static information to a point that had the original of the
full, up-to-date information was a superfluous activity.
So, back to a financial institution selling a customer a stale, static
credential. It is possible. There is a need for stale, static
credentials in the original design point for such credentials
.... electronic, offline between parties that have had no previous
business relationship.
Note however, just because a financial institution has sold a customer
a stale, static credential ... so that customer can use it to perform
offline electronic transactions with entities that customer previously
had not knowledge .... doesn't mean that the financial institution
should revert an online, real-time payment infrastructure to stale,
static offline operation and loose important risk management
characteristics of having real-time aggregated information. Furthermore,
just because an organization wants to get off an online system that
uses userids and passwords and go to a public key operation
... doesn't mean that they have to revert to an offline system with
stale, static credentials.
For instance m'soft 2000, most unix'es and mainframes provide for
Kerberos security access control. The draft pk-init document that
defines the use of digital signature authentication to a kerberos
environment specifies (in effect) that the digital signature can be
authenticated either from an offline,stale, static credential or from
an online userid database where the public key has been registered in
lieu of a password.
Problem with userid/password being addressed with digital signature
authentication doesn't automagically equate digital signature with
offline, stale, static credentials. A digital signature
authentication environment can be either online or offline
paradigm. There can be perfectly valid reasons why somebody might want
to move from an online userid/password paradigm to a offline digital
signature paradigm using offline, stale, static
credential/certificates. On the other hand there might also be reasons
why an operation might want to move from an online userid/password
paradigm to an online userid/publickey paradigm.
In prior note about existing web-based certification authorities doing
real-time operation ... rather than providing a stale, static
credential to you that you can present to others ... there are current
web-base certification authorities that are sending real-time
information to the business operations certifying the
information. This is model analogous to current real-time payment
network. These web-based certification authorities seem to be fairly
active and doing a large business. It also appears to be an attractive
business model ... since they are charging these other businesses on a
per transaction basis ... as opposed to charging the customer up front
for a stale, static credential.
FSTC (the organization currently hosting this payment mailing list)
has seriously looked at this business model of doing real-time
transactional certification within their FAST (financially
authenticated secure transaction) project. The offline certification
authority model has the certification authority selling the customer a
stale, static credntial so that customer can do business with some
other entity. The online certification authority model has real-time
certification transactions occuring directly with the business that
the customer is dealing with (and directly charging that business
rather than the customer).
At 100,000 feet this is in effect the current online payment
infrastructure model ...... where the attribute/characteristic being
certified is the ability to pay based on the current instantaneous
account balance. The FAST project is all about extending the
real-time certification transaction of the payment business to other
attributes. One of the most commonly mentioned attribute would be age
... however in the real-time transaction certification (as opposed to
the offline paradigm with stale, static credentials) a business might
ask the financial institution something about the customers age
.... like over 21, under 14, at least 18, over 55, etc. The financial
institution just send back a certified real-time answer ... basically
yes/no.
There is no stale, static credential sold to the customer. Furthermore,
this is similar to the major business of a fair number of the existing
web-based real-time certification authorities. They are making a
booming business doing real-time age certification transactions (as
opposed to selling stale, static credentials to the customer ... they
are doing real-time transaction charging to the businesses that the
customer is dealing with).
- there can be closed online certification authority operations
- there can be open online certification operations ....
- there can be open offline certification operations and
- there can be closed offline certification operation.
A closed offline certification operation are the relying-party-only
certificates issued in the past by financial institutions, in part to
avoid including privacy information in a certificate. An open offline
certification operation can be the traditional X.509 identify
certificates that have been the object of standardization for at least
the past ten years.
A open online certificatinon operation can be the current online
debit/credit/atm payment operation ... even tho it currently doesn't
use digital signatures or public key ... it is still an open, online
certification operation (and x9.59 could extend it to an open online
certification operation with digital signatures and public
key). Another open, online certification would be the current online
web-based operations that do things like certify age (again w/o using
digital signatures). A proposal for an open, online certification
would be the FSTC FAST project that has the option of being done with
digital signatures.
Kerberos can be deployed as either open or closed online certification
operation ... depending on what the cross-domain certification
agreements are. The issue of whether Kerberos is deployed as open or
closed is pretty independent of its authentication procedure. It will
provide cross-domain open online certification independent of using
userid/password for authentication. The pk-init internet standards
draft for Kerberos digital signature authentication is independent of
whether kerberos is deployed for open online certification operation
or closed online certification operation. Also, whether the public
key for digital signature authentication is extracted from a
certificate or from the Kerberos userid database is independent of
whether kerberos is configured for open or closed online certification
operation.
For various technical reasons associated with the offline design
point, certificates infastructure have had to equate the digital
signature authentication and the information being certified into a
single operation. Just because they are packaged that way in a
certificate doesn't mean that they are equivalent in a business
sense. In a business sense
offline/online
authentication mechanism
open/closed
are all independent operations (even tho certificates have chosen to
package them together).
However, it is a totally false to claim that just because something
doesn't use public key from a certificate ... that it is a closed
certification process. The attributes of open/close, method of
authentication, and offline/online are all indepentent business
characteristics (regardless of how some particular certification
operation has chosen to implement them).
There is online payment network which is an open certification system
that just currently doesn't happen to use digital signature
authentication ... but does realtime online payment certification
transactions (as opposed to offline stale, static credential
certificates)
There are online web-based age open certification that do realtime
online age certification transactions that happen to currently use
userid/password (again not offline, stale, static credential
certificates).
There is the FSTC FAST project that has looked at extending the open
online payment certification transactions to attributes other than
ability to pay
The is X9.59 digital signature authentication standard that extends
the existing online payment network realtime transaction to digital
signature authentication. It is possible to apply the X9.59 approach
for payment authentication to the open online FSTC FAST extensions of
doing real-time certification of attributes other than payment
(generalizes open, online attribute certification with digital signature
authentication w/o certificates)
There is Kerberos that does online certification that can be
configured for either open or closed (depending on the cross-domain
kerberos aggreements). Kerberos is currently userid/password based for
authentication (which is independent of whether it has open or close
attribute). PK-init draft is extending kerberos standard to also
support digital signature authentication .... allowing both
certificate based digital signature authentication and
userid/publickey database based digital signature authentication. The
issue of userid/password authentication. certificate-based digital
signature authentication or userid/publickey database digital
signature authentication are orthogonal to whether kerberos online
certification has been configured for open or closed.
anders.rundgren@xxxxxxxx on 5/31/2002 2:02 am wrote:
>a possible issue for financial institutions, once they have "already done
>the RA-part for free" ... would they then issue certificates that have
>design point of both 1) offline environment and 2) for people with no prior
>business relationship .... or would they acknowledge that the world has
>significantly moved towards an online, real-time environment (like they
>have for payment transactions) and any significant need for the old offline
>design point that certificates were invented for has possibly passed on by.
Lynn,
I would put it in another way. Enterprises want to get away from user-IDs
and passwords. If their employees once register in the PA-system using
an FI-issued identity in the form of a certficate, companies do not have to
jump into the CA-business and employees get long-lived (renewable) static
credentials that they can use for many puposes. That's worth $10-$25/y.
When you leave a company your entry in the PA-system is simply
deleted. There is nothing to revoke, take back etc. Such a PKI-resource
can be used for both on-line and off-line operations.
When I wrote "the individual's own trusted parties" I referred to parties
where you probably have a strong relationship with. But you could actually
remotely sign-up for any kind of service using such a credential.
The FI-issuer can under your command (using your PKI-credential),
create a signed document that contains other data about yourself that
the service may need to accept a new member. That may include
finanicial statements, date-of-birth, gender, nationality, address,
photo, or whatever they have registered on you. I.e. an attribute
cerificate of some kind.
Non-certificate schemes OTOH, like the ones you are advocating for
(AADS) are similar (I would say identical) to closed PKIs.
If we right now think that technological problems of various kinds is
the major problem, I'm sure that the FUTURE battle will be about:
Open versus closed PKIs.
We apparently have different beliefs here and since at this stage we
are really talking about "beliefs" rather than absolute truths, we just
have to wait another 5 years or so to see what happends.
I'm personally trying to make the open PKI more practical as at least
in a many-to-many, plug-and-play, B2B-environment, I cannot really see
any viable alternative to open PKI. OBI Express, my "baby", is one of
the first B2B standards-to-be that are entirely based on open PKI and
digital signatures. When the new HW-crypto-box that IBM is beginning
to put in standard low-end PCs, reaches servers as well, security can be
in the same leage as for VPNs, but at 2-5% the cost of thoose.
cheers,
Anders
X-OBI
Royal Mail pulls plug on ViaCode digital certificate
From: Lynn Wheeler
Date: 05/31/2002 01:05 PM
To: internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Royal Mail pulls plug on ViaCode digital certificate
http://www.theregister.co.uk/content/6/25496.html
ALARMED ... Only Mostly Dead ... RIP PKI ... part III
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/31/2002 02:36 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>,
sberinato@xxxxxxxx, sscalet@xxxxxxxx, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI ... part III
oh, trivial example of the online certification vis-a-vis offline
certification by financial institutions for say employment.
In the online certification (using the FSTC FAST model), the application
signs a message containing their name, address, public key, financial
institution, account no ... and whatever other information the applicant is
asserting ... plus the employer and current date/time. The employer sends
it off to the financial institution ... the financial institutions
cross-checks the asserted information (note that XML tags would be really
helpful for automating this) and sends back a certification yes/no as to
the asserted information. the bank charges the employer for the online
certification. the scenario is that the asserted information is tailored
specifically to the type of transaction and to maybe what the bank is
willing to deal with. Note that in this scenario ... the public key is just
another piece of asserted information. The bank looks at the signed request
... and validates my signature and each individual piece of asserted
information and returns a realtime, online, dynamic, up-to-date, non-stale
yes/no response as to the accuracy of the asserted information.
Now in the case of a generalized offline certification using certificates
.... a year ago my bank issued me a certificate with all possible asserted
information that covers all possible scenarios that might ever possible
arise in the future. I might make different types of assertions to
different kinds of entities that i need certified ... a one-size-fits-all
kind of certificate needing to have all possible types of information that
i might ever need to be certified (names, addresses, age, history, balance,
citizenship, etc, etc). The other choice is i get a couple dozen different
certificates certified with different combinations of information covering
all possible situations that might ever possible arise in the future.
A third choice is i get a dozen very specific certificates ... each
certificate specific with one and only one piece of certified information
... i keep all such certificates around ... and when i want to assert a
specific set or combination of information .... i present the appropriate
combination of certificates.
Now, however I do it, I'm still presenting stale, static certified
certificate information. There is some high probability for any event
of any importance and/or value ... the entity I'm dealing with is
going to still want to make a real-time validation of at least some
piece of the information (i.e. call up the bank to see if anything has
changed in the last 12 months). So even in the case of the offline
certification operation, except for matters of no-importance and
no-value ... the business entity is probably going to make a real-time
check as to the timeliness of at least some of the asserted/certified
(stale, static) information. The financial institution still gets
their FSTC FAST realtime, online transaction which they can directly
charge on a transaction basis as to the accuracy of the asserted
information being certified.
Now as to the proxy PKI ... this can be considered the online
certification in disquise. I make some assertions (like in the online
payment system ... that I assert to a merchant that I pay for the
operation). The merchant accepts the assertion and sends it to the
appropriate online certification authority (i.e. issuing financial
institution) which does a real-time certification of the assertion and
returns the certification to the merchant. The slight difference is
that I send the assertion directly to the proxy PKI w/o it having to
pass thru the merchant first. Now, in previous discussions it has been
pointed out that a online, realtime certification authority can
provide realtime certification.
This realtime certification (say a automated purchasing agent that
verifies that I actually have budget and authority to order something)
does its check before certifying it .... say in a B-to-B environment.
Now the B-to-B environment can either be offline certification
... with digital signatures and certificates so that B-to-B entities
with no previous relationship can directly deal with each other ... or
it can be with digital signatures and accounts. The account mechanism
is how things are done today .... business first establish a business
relationship and create account records that represent that business
relationship. As part of that business relationship they register
various kinds of information in their account records ... which can be
maintained in real-time (active, in default, etc). One of the kinds of
information that can be put in account records is a public key.
The other alternative is that in the b-to-b environment there is no
prior business relationship established ... sort of a hit-and-run,
one-of-a-kind business transaction ... this can be either addressed
with
1) offline certificate credentials with stale, static information
certified by trusted financial institition
2) online certification where each business checks with trusted
financial institution (as in the employee applicant scenario given
earlier).
also:
https://www.garlic.com/~lynn/aadsm11.htm#40
PKI: Only Mostly Dead
Refed: **, - **, - **
From: Lynn Wheeler
Date: 06/10/2002 04:58 AM
To: pgut001@xxxxxxxx (Peter Gutmann)
cc: cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
nobody@xxxxxxxx, pgut001@xxxxxxxx,
Subject: Re: PKI: Only Mostly Dead
I think there is even less "I" than most people suspect. I've recently
taken to some manual sampling of SSL domain name server certificates
... and finding certificates that have expired ... but being accepted
by several browsers that i've tested with (no complaints or fault
indications).
there was thread in another forum where I observed that back when
originally working on this payment/ecommerce thing for this small
client/server startup that had invented these things called SSL &
HTTPS ... my wife and I had to go around to various certificate
manufactures with regard to some due diligence activity. I think w/o
exception that they all made some comment about the "PK" being
technical ... and the "I" being service ... and providing "service" is
an extremely hard thing to do (and they hadn't anticipated how really
hard it is).
some past ssl domain name certificate threads:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
As i've observed previously there are a number of ways that the
technical stuff for "PK" can be done w/o it having to equate to
(capital) PKI ... some recent threads on this subject:
https://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
https://www.garlic.com/~lynn/aepay10.htm#32 some certification & authentication landscape summary from recent threads
https://www.garlic.com/~lynn/aepay10.htm#34 some certification & authentication landscape summary from recent threads
https://www.garlic.com/~lynn/aepay10.htm#35 some certification & authentication landscape summary from recent threads
https://www.garlic.com/~lynn/aadsm11.htm#18 IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#19 IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#20 IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#21 IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#22 IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#25 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#26 Proxy PKI
https://www.garlic.com/~lynn/aadsm11.htm#27 Proxy PKI
https://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm11.htm#32 ALARMED ... Only Mostly Dead ... RIP PKI
https://www.garlic.com/~lynn/aadsm11.htm#33 ALARMED ... Only Mostly Dead ... RIP PKI
https://www.garlic.com/~lynn/aadsm11.htm#34 ALARMED ... Only Mostly Dead ... RIP PKI
https://www.garlic.com/~lynn/aadsm11.htm#35 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
https://www.garlic.com/~lynn/aadsm11.htm#36 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
https://www.garlic.com/~lynn/aadsm11.htm#37 ALARMED ... Only Mostly Dead ... RIP PKI
https://www.garlic.com/~lynn/aadsm11.htm#38 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
https://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
https://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
https://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
pgut001@xxxxxxxx at 6/1/2002 2:18am wrote:
>Peter Gutmann should be declared an international resource.
Thankyou Nobody. You should have found the e-gold in your acount by now :-).
>Only one little thing mars this picture. PKI IS A TREMENDOUS SUCCESS WHICH IS
>USED EVERY DAY BY MILLIONS OF PEOPLE. Of course this is in reference to the
>use of public key certificates to secure ecommerce web sites. Every one of
>those https connections is secured by an X.509 certificate infrastructure.
>That's PKI.
"Opinion is divided on the subject" -- Captain Rum, Blackadder, "Potato".
The use with SSL is what Anne|Lynn Wheeler refer to as certificate
manufacturing (marvellous term). You send the CA (and lets face it,
that's going to be Verisign) your name and credit card number, and get
back a cert. It's just an expensive way of doing authenticated DNS
lookups with a ttl of one year. Plenty of PK, precious little I.
>The truth is that we are surrounded by globally unique identifiers and we use
>them every day. URLs, email addresses, DNS host names, Freenet selection
>keys, ICQ numbers, MojoIDs, all of these are globally unique!
>"pgut001@xxxxxxxx" is a globally unique name; you can use that
>address from anywhere in the world and it will get to the same mailbox.
You can play with semantics here and claim the exact opposite. All of
the cases you've cited are actually examples of global distinguisher +
locally unique name. For example the value 1234567890 taken in
isolation could be anything from my ICQ number to my shoe size in
kilo-angstroms, but if you view it as the pair { <ICQ domain>,
<locally unique number> } then it makes sense (disclaimer: I have no
idea whether that's either a valid ICQ number or my shoe size in
kilo-angstroms).
(This is very much a philosophical issue. Someone on ietf-pkix a year
or two back tried to claim that X.500 DNs must be a Good Thing because
RFC 822 email address and DNS names and whatnot are hierarchical like
DNs and therefore can't be bad. I would suspect that most people view
them as just dumb text strings rather than a hierarchically structured
set of attributes like a DN. The debate sort of fizzled out when
no-one could agree on a particular view).
I think the unified view is that what you need for a cert is a global
distinguisher and a locally meaningful name, rather than some complex
hierarchical thing which tries to be universally meaningful.
Frequently the distinguisher is implied (eg with DNS names, email
addresses, "for use within XYZ Copy only", etc), and the definition of
"local" really means "local to the domain specified in the global
distinguisher". I'm not sure whether I can easily fit all that into
the paper without getting too philosophical - it was really meant as a
guide for users of PKI technology.
Peter.
Web site exposes credit card fraud
From: Lynn Wheeler
Date: 06/27/2002 06:08 AM
To: Internet-Payments List <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Web site exposes credit card fraud
http://www.cnn.com/2002/TECH/internet/06/26/identity.theft.ap/index.html
Web site exposes credit card fraud
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 06/27/2002 06:49 AM
To: Internet-Payments List <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: Web site exposes credit card fraud
oh yes ... misc. past threads in this area:
https://www.garlic.com/~lynn/subintegrity.html#fraud
and specific thread on security proportional to risk specifically with
respect to cc nos.
https://www.garlic.com/~lynn/aepay10.htm#20 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#24 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#25 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#28 Security Proportional to Risk (was: IBM Mainframe at home)
lynn.wheeler@xxxxxxxx on 6/27/2002 8:08 am wrote
http://www.cnn.com/2002/TECH/internet/06/26/identity.theft.ap/index.html
Giuliani: ID cards won't curb freedoms
Refed: **, - **, - **
From: Lynn Wheeler
Date: 06/28/2002 06:20 AM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: cryptography@xxxxxxxx,
Digital Bearer Settlement List <dbs@xxxxxxxx>
Subject: Re: Giuliani: ID cards won't curb freedoms
i was in the audience ... and i'm pretty sure that the id-card subject
was only in short response to question asked from the audience. this
was the e-gov conference (dan greenwood was on the podium the day
before giving out awards from mit for web-stuff excellence).
cards were mentioned a few of times in various conference sessions ...
the primary focus of attendees was generally terrorists or other
disasters ... with lot of specific focus on IT related aspects
(helping manage the incident and/or as points of vulnerabilities)
.... this was something of a dataprocessing event with it
professionals of one sort or another. sort of a straw poll ... i could
guess that 2/3rds of the times that cards were brought up during
sessions ... it was in the context of not working.
of course ... within the context of my aads chip strawman .... i have
some opinion about that.
rah@xxxxxxxx on 6/26/2002 3:57 pm wrote:
http://news.com.com/2102-1017-939499.html
Giuliani: ID cards won't curb freedoms
By Margaret Kane
Staff Writer, CNET News.com
June 26, 2002, 9:00 AM PT
http://news.com.com/2100-1017-939499.html
WASHINGTON--U.S. citizens may need to carry national identification cards
someday, but that doesn't need to translate into a loss of fundamental
freedoms in the name of safety, former New York Mayor Rudolph Giuliani said
Wednesday.
"We need a better way to properly ID people that's more effective (than
current means). There's a trade-off we have to make between privacy and the
protection of everybody...in society," said Giuliani, following a keynote
speech at the E-Gov 2002 conference here. More than 10,000 people are
attending the four-day conference, which concludes Thursday.
A national ID system has become a hot-button issue within the tech industry
and nationally. Technology experts and privacy advocates have been debating
the merits of national ID cards and other identification systems and trying
to figure out how to make sure they wouldn't be abused.
Giuliani said ID cards do not necessarily equal a loss of freedom, adding
that other democratic countries require citizens to carry ID cards.
"We have to separate fundamental freedoms...from those things that we had
the luxury to do in the past," he said.
Giuliani's speech was met with standing ovations and flag waving from the
crowd at the show, which included employees of federal, state and local
governments. The conference here is being run jointly with one on "homeland
security," reflecting a new focus from the technology world and the
government of using IT for defense.
Giuliani discussed ways that technology aided him as mayor, including
helping him handle the terrorist attacks of Sept. 11.
Before those attacks, Giuliani's best-known achievement had been lowering
the city's crime rate, a feat he said was greatly helped by the use of
technology to conduct daily monitoring of crime.
The city had previously analyzed crime statistics on a yearly basis, but he
initiated a program that helped track crime at the precinct level on a
daily basis and plotted that data on geographic and time bases to more
efficiently deploy police officers.
Similar programs were used in the city's correctional facilities to help
reduce violence at Riker's Island by 80 percent, he said.
Technology also helped open up the city to citizens, he said, making their
lives easier. For instance, New York has put in place ways for citizens to
use the Internet to pay parking tickets and apply for permits for
everything from opening a restaurant to tackling new construction.
"One of the great complaints about government, certainly in New York City,
was that it was unusable...and unmanageable," he said. "E-government is a
way to change that."
Giuliani's Emergency Management System, created in 1996, used technological
simulations to train for emergencies including terrorist attacks, fires and
other crisis, Giuliani said.
"I can't emphasize more how important that it is to prepare for the worst
thing you can imagine," he said. "Using technology to try and play games
for what might happen, even if they're not exactly right when the
emergencies occur," is an important way to prepare.
Giuliani cautioned attendees to prepare for the unexpected but to remember
that "life goes on."
"At home, we have to do everything we can to be better prepared," he said.
"At the same time, we have to get people to relax and go about their daily
lives."
Giuliani disagreed with the notion that the world is now a more dangerous
place.
"It was as if a curtain was in front of us; we saw the world the way we
wanted to see it. Now the curtain has been lifted, and we can see the world
the way it really is," he said. "Having said that, and recognized that,
even before doing anything about it we're safer."
Asked if he would be interested in becoming secretary of the proposed
Department of Homeland Security, Giuliani said that he hadn't decided on
his future but that the job that he really wanted was to become "general
manager of the (New York) Yankees."
maximize best case, worst case, or average case? (TCPA)
From: Lynn Wheeler
Date: 06/30/2002 08:06 AM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: cryptography@xxxxxxxx,
Digital Bearer Settlement List <dbs@xxxxxxxx>, dcsb@xxxxxxxx
Subject: Re: maximize best case, worst case, or average case? (TCPA)
I remember looking at possibility at adding tamper resisistent
hardware chip to PCs back in 83 or 84 time frame (aka the TCPA idea
for PCs is going on at least 20 years old now). It was the first time
I ran into embedding chip in a metal case that would create electrical
discharge frying the chip if the container was breached.
Remember when applications came with their own copy-protection floppy
disks? .... it was possible to build up a library of such disks
.... requiring all sorts of remove, search, insert ... when switching
from one application to another. They eventually disappeared ... but
imagine if they had survived into the multitasking era .... when it
would have been necessary to have multiple different copy protection
floppy disks crammed into the same drive at the same time. The chip
was suppose to provide an analog to the CPU serial number used for
licensing software on mainframes .... dating at least from the
original IBM 370s (store cpuid hardware instruction).
Some of the higher-end applications still do that with some form of
dongle (originally in the serial port) that comes with the application
.... it doesn't quite have the downside of trying to cram multiple
floppies into the same drive concurrently; the serial port dongles
allow for them to be inline cascaded ... and in theory still be able
to use the serial port for other use at the same time.
i believe that there is some statistic some place about the UK and the
US are really great .... that in those two countries the copyright
piracy is estimated to only be 50 percent.
AADS Postings and Posting Index,
next, previous
- home