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:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59 ... fyi
http://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):
http://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
http://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):
http://www.garlic.com/~lynn/aadsm11.htm#0 Basic credit card payment question
http://www.garlic.com/~lynn/aadsm11.htm#1 Basic credit card payment question
http://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
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
http://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):
http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
misc. past finread posts:
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
http://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).
http://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 guarentee 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:
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://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 cateloging and maintain complex information may be
required .... like something like we do in attempting to mirror the IETF
process
http://www.garlic.com/~lynn/rfcietff.htm
or the complexities of taxonomies (& glossaries):
http://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:
http://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.
http://www.garlic.com/~lynn/secure.htm
is the merged security glossary.
for more info about merged glossaries and sources see:
http://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:
http://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
http://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):
http://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
http://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
http://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
http://www.iso.org/tc68
(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:
http://www.garlic.com/~lynn/subtopic.html#fraud
a specific discussion/thread
http://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:
http://www.garlic.com/~lynn/96.html#16 middle layer
http://www.garlic.com/~lynn/96.html#17 middle layer
http://www.garlic.com/~lynn/98.html#50 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#123 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#124 Speaking of USB ( was Re: ASR 33 Typing Element)
http://www.garlic.com/~lynn/99.html#201 Middleware - where did that come from?
http://www.garlic.com/~lynn/99.html#202 Middleware - where did that come from?
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001j.html#4 I hate Compaq
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2001n.html#23 Alpha vs. Itanic: facts vs. FUD
http://www.garlic.com/~lynn/2001n.html#34 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
http://www.garlic.com/~lynn/2002.html#2 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002b.html#4 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#37 Poor Man's clustering idea
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is)
http://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:
http://www.garlic.com/~lynn/x959.html#x959
also reference to the nacha/debit/atm pilot
http://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
http://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):.
http://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 useable 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:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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
http://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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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:
http://www.garlic.com/~lynn/aadsm11.htm#19 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#25 Proxy PKI. Was: IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#26 Proxy PKI
http://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:
http://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
From: Lynn Wheel