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 guarantee that key pairs are never submitted for multiple certificates if they only certify random keys that the CA generate themselves .. and that creating a new certificate always requires generating a new key pair (unless there is a global repository used by all CAs checking to see if a specific key-pair had ever previously been certified).

2) moving the certificate inside the signed message. the reason to do this is the original suggestion involving the flag bits indicating the senders belief as to the flag indicating message type/characteristic needs to be part of the signed message. moving the whole certificate inside the signed message is somewhat overkill just to get a couple bit indicators moved inside. this solution requires a convention that signers always include flags indicating their belief as to the type of message (people doing brain-dead signing of messages w/o looking at the contents might get themselves into situation similar to people signing blank checks or blank pieces of paper).

previous pieces of thread:
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 usable for all electronic retail transactions in all environments.

note the current predominate WEB infrastructure send credit card information from the client to the merchant. The WEB merchant takes that in transforms it directly into a 8583-like message that is pumped into the credit card network (via the merchants acquiring processor interface). The original WEB merchant implementations effectively emulated the same process that the electronic point-of-sale terminal used to interface into the merchant's acquiring processor interface. misc. refs:


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 Wheeler
Date: 05/28/2002 05:15 PM
To: Chuck Wade <chuck@xxxxxxxx>
cc: Internet Payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI
I was on a PKI panel at NISSC conference a couple years ago. The first three speakers were from the traditional PKI vendors and their basic message was something to the effect that .... everybody has heard all the stories about how really hard PKIs are ... well, I'm here to tell you that it is much, much easier than you've heard.

I then gave a AADS talk

Then the last speaker made some opening statement to the effect that .... they were responsible for the oldest and largest PKI in existance (some DoD thing) and everybody has heard all the stories about how really hard PKIs are ... will, I'm here to tell you that it is much, much harder than you've heard.

Now a couple years before that, my wife and I had been doing this stuff associated with electronic commerce.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

and we had a couple decades experience between us with data processing that provided industrial strength service operations. So one of the things that we did as part of this SSL thingy was go around and perform due diligence on the major PKI operations and talk about what it means to operate an industrial strength service. I think w/o exception the response was that they were starting to find that out ... that they had gone into it with the idea that it was somehow a computer or cryptographic technology thing and were finding out that the computer stuff and the crypto stuff represented possible 5 percent of what they needed to do.

The AADS stuff isn't so much about certificates or no certificates ... it is about industrial strength service operations are really hard to do right ... and incorporating public key into an existing service operation may have significant upfront effort just to get off the ground (aka AADS) compared to deploying a simple, stand-alone CA server (aka CADS) ... but AADS then is able to take advantage of significant investment in existing infrastructures for providing industrial strength data processing service ... and opposed to growing it from scratch for a brand-new operation.

Simple CA servers are pretty straight forward ... comparable to say any other departmental server effort. It is making the transition from simple departmental server stuff into large scale industrial strength data processing that lots of other issues start to raise their head (the transition from 10-20 person departmental service to a several hundred thousand person enterprise service is not necessarily a straight forward or even linear scale-up).

chuck@xxxxxxxx on 5/28/2002 4:07 pm wrote:
lynn.wheeler@xxxxxxxx wrote:
> http://www2.cio.com/research/security/edit/a05232002.html Lynn,

Thanks for passing along the reference to the ALARMED editorial in CIO by Scott Berinato. It manages to come a bit closer to the truth than have many of the other pieces written on the death of PKI.

I would add a couple of observations of my own. First, the financial industry itself is largely responsible for escalating the requirements of PKI systems and services to truly absurd levels. Building massive infrastructure with extreme security appealed to the investment community that was happy to finance the PKI endeavors of multiple startups and spinoffs. After all, if the major banks were all saying they needed this stuff, then it must be a good investment to back the folks building these PKI palaces and Maginot Line defenses.

It is interesting to reflect on the original concepts for PKI systems (developed long before the term "PKI" came into use). These concepts envisioned simple workstation systems with addon security hardware for key protection that would operate as Certification Authorities (CAs) out where the credentials were being issued. The US DoD secure messaging systems actually deployed such CAs. The early Netscape server products also included simple CA software solutions, still used by many today. Microsoft offers similar CA solutions as well.

What is unfortunate in the current dialogue is how few people discuss the successes of PKI in their rush to be among the first to stamp on the grave of PKI. In reality, PKI is widely used today, and not just for SSL server side authentication and key exchange. Many organizations effectively use secure email solutions (e.g., S/MIME) with standard X.509 certs (I regularly conduct sensitive client business using S/MIME and certs I conveniently acquired from Thawte's service). Lotus Notes is very popular with many corporations, and is based on public key certificates, although only recently has Notes begun to use standard certs instead of their earlier proprietary constructs.

But more importantly, and perhaps more to the point, the core concept of digitally signing a public key remains central to many applications of public key cryptography. Furhtermore, public key crypto remains a useful security technology that can be applied to a wide range of problems. Whether or not a signed document containing a public key is called a certificate, or something else, is mostly a matter of terminology and choice of standards.

Lynn, before you jump in with any claims about the virtues of AADS, I will acknowledge that certificate-like objects are not always required, especially when the appropriate keys (private and public) can be selected through some other context, such as the name or userid or account number of one of the parties. Hopefully, you will also agree that there are also situations where parties do not know "a priori" the public keys of the other parties, and some sort of mechanism is required to exchange and confirm the authenticity of the public keys.

So, as Mr. Berinato's editorial points out:


> "As complex as Public Key Infrastructure is,
> the theory is sound."


> "So while the concept behind PKI was appealing,
> everything else about it was shoddy."

Both are accurate observations, although I would tend to refer to commercial PKI solutions as more "overblown and gilded" than "shoddy," although I do know of some examples of shoddy PKI systems.

My conclusion is that PKI has come to mean a "poorly chosen path" for achieving effective deployment of security measures based on public key cryptography. The PKI path has favored entrenched interests and "big iron" solutions. This path has also confused many about what the ultimate destination should be. What needs to be recognized--and more broadly communicated--is that there are other paths to achieving effective use of public key crypto as a set of mechanisms for building secure applications. We need to stop focusing on the wrongness of the PKI path, and move the debate to more constructive dialogues about what the right path (or paths) should be. To this extent, I appreciate the suggestions that Anders has been putting forward because I believe he's talking about possible new paths, not bemoaning how we got here.

Just some thoughts...
--
...Chuck Wade
Consultant, Internet Security and Financial Services
   +1 508 625-1137  Office Phone/Voice Mail
+1 309 422-9871  Fax Service


ALARMED ... Only Mostly Dead ... RIP PKI

From: Lynn Wheeler
Date: 05/29/2002 10:21 AM
To: Chuck Wade <chuck@xxxxxxxx>
cc: Internet Payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI
I believe the reason that certificates were "invented" was to provide a basis for trust between parties that had no prior relationship in an offline environment .... aka the letters of credit analogy from the days of sailing ships and before telephone & telegraph. These were the days of offline email when you would connect to the local POP and download your email and then hang-up. It was then necessary to authenticate the sender of email in situation where you had no prior knowledge/relationship with the sender.

note that early on we coined the term certificate manufacturing to distinguish the SSL environment from PKI. straight certificate manufacturing operation was somewhat simpler than a real service operation.

chuck@xxxxxxxx on 5/29/2002 8:49 am wrote:
The reason that certificates were "invented" was that new applications for public key cryptography emerged where "a priori" knowledge of public keys could not be assumed. Secure email is a classic example of an application where there is a need to exchange public keys between parties where there is no prior knowledge of the other party's keys. SSL web sessions represents another such application as do some payment applications (e.g., the FSTC eCheck initiative). I should also acknowledge that different approaches for creating public key certificate-like structures do exist, along with different trust models.

The danger in continuing to flog the "dead" PKI horse is that it further deflects attention away from the more relevant problems of inadequate commercial solutions for any of the critical security problems confronted by individuals, businesses and governments. The ongoing debates surrounding authentication services serves to sharply illustrate just how little progress has been made. Furthermore, the current climate continues to promote a contentious atmosphere with bitter competitive rivalries and conflicting priorities undermining many efforts to make forward progress.

To my earlier point, our current definition of PKI should be viewed more as a path that is no longer going anywhere useful. The options are to:

backtrack to some earlier stage of development and start anew,

somehow switch onto another path that shows greater promise,

or pick a new direction and take advantage of what progress has already been achieved.

Each of these options has its advocates, but I'll admit that I tend to favor the latter option on pragmatic grounds.

What is even more important, however, is to focus on the critical needs for effective security measures that can be widely deployed and adopted, and that can evolve rapidly to confront an array of new threats.

Let's be honest, the security of payment transactions today is far worse than it was a decade ago. This is due to the failure to improve security measures for payment transactions, while broader information dissemination and new technologies have enabled an array of new threats with corresponding risks. Put differently, the "moral hazards" embedded in our current payments infrastructure are of historic proportions, and the trends are not looking healthy right now.

Therefore, debating the "death of PKI" is a distraction that deflects attention from the true problems. It is high time we focus on better ways to mitigate the security risks associated with both legacy and new payment transaction services. The need for public key infrastructure to support new security measures can then be defined rationally based on real requirements instead of impossible or conflicting objectives. My personal suspicion is that the eventual solutions will have aspects of many of the current models, but without so much baggage.

Does this make sense?

Regards...
--
...Chuck Wade
Consultant, Internet Security and Financial Services
+1 508 625-1137  Office Phone/Voice Mail
+1 309 422-9871  Fax Service


ALARMED ... Only Mostly Dead ... RIP PKI .. addenda

Refed: **, - **, - **
From: Lynn Wheeler
Date: 05/29/2002 04:17 PM
To: Chuck Wade <chuck@xxxxxxxx>
cc: Internet Payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
now the original assumptions for the invention of certificates were 1) no prior relationship and 2) offline (aka the letter of credit credential from sailing ship days).

now in the financial standards body there is a standards effort called certificate credential (x9 sixty something or other) ... in part because of the extremely onerous payload overhead that a typical x.509 certficate represents to all of the payment networks

note however in the effort for certificate size reduction one of the techniques is recognizing that the original assumptions for the invention of certificates don't usually apply to modern day payment transactions .... typical there is a prior business relationship between a financial institution and there account holder and for electronic transactions (that might involve a digital signature) the transactions are mostly online.

recognizing this, one of the techniques in the certificate compression activity is that some fields can be eliminated (from a typical x.509 certificate) because there are prior business relationships between a financial institution and their customer. The analogy might be tthe letter of credit credential design to introduce a customer of the bank of england (?) to the president of some bank in south america (sailing ship days before the invention of telegraphy and telephone). So we have a customer of the bank of england that wants to do payment transaction with the bank of england ... he goes to the president of the bank of england and requests a letter of credit credential introducting himself (the customer) to the president of the bank of england. The president of the bank of england writes such a letter of credit credential for the customer that will introduce the customer to the the president of the bank of england and gives it to the customer. The customer then turns around and gives it back to the president of the bank of england (i.e. the president of the bank of england introducing the customer to the president of the bank of england).

so the x9 sixty something or another recognizes that there can be some things that aren't really necessary in a payment certificate .... compared to the x.509 original certificates targeted for offline introduction between two entities that have had no prior business relationship. well, being aggresive in that effort for a situation where the customer is the customer of the bank and the payment transaction is online (effectively negating the original assumptions for the invention of certificates) .... it is possible to compress/eliminate all fields in a typical x.509 certificates so the certificate now has zero fields.

the question now is what is the size of a x.509 certificate that has all fields eliminated? which would represent an extremely aggresive application of compression to the extremely onerous payload that a typical x.509 certificate reprsents to the payment netwoirks.

ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/29/2002 08:18 PM
To: Chuck Wade <chuck@xxxxxxxx>
cc: Internet Payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
that should have been certificate compression ... not certificate credential (x9 sixty something or another) to handle the extremly onerous payload penalty that a standard x.509 certificate size represents in all the traditional payment networks.

now as to the SSL stuff ... the long version is at: http://www.garlic.com/~lynn/subpubkey.html#sslcerts

a much shorter version is that certificates represent trust ... nominally between two parties that otherwise have no prior relationship in an offline envrionment (or at least an environment where there aren't online resources that can be relied upon).

so SSL certificate is basically to check that the domain name in the entered URL matches the domain name in the certificate (can I trust that i'm actually talking to the id adress that i believe i'm talking to). the justifcation for all this is there is some question regarding the integrity of the domain name infrastructure that provides the domain name to ip-address translation for all internet operations .... so we'll use a trusted certificate to provide a redundant check as to the integrity of the domain name infrastructure provided information. So how does the CAs check the validity when somebody applies for a SSL certificate? Well, CAs or certification authorities ... nominally go to the authoritative agency for the information to validate accuracy. So who is the authorative agency(s) for domain names that certification authorities check with with regard to SSL certificates? well it turns out that they have to check with the domain name infrastructure (because the domain name infrastructure is the authoritative agency for domain names) ... this is the very same domain name infrastructure that is the subject of integrity issues giving rise to the requirement for SSL certificates in the first place. The long & short of it is that there are some specific suggestions about how to improve the integrity of the domain name infrastructure .... so that certification authorities can trust the information that they validate as part of going about issuing trusted SSL domain name certificates ... however, the improvement of the integrity of the domain name infrastructure (for the purposes of certification authorities) also can eliminate the original justification for having SSL domain name certificates in the first place.

ALARMED ... Only Mostly Dead ... RIP PKI

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 05/30/2002 04:49 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>,
    sberinato@xxxxxxxx, sscalet@xxxxxxxx, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI
as noted in previous note ... we had coined the term certificate manufacturing to distinquish SSL environment from PKI early on when we were working with this small client/server startup in menlo park that wanted to do payments in conjunction with this thing they had developed called SSL.

other related discussions regarding SSL http://www.garlic.com/~lynn/subpubkey.html#sslcerts

anders.rundreg@xxxxxxxx on 5/30/2002 1:40 am wrote:
I think I'm less alarmed. As noted by Chuck Wade, PKI is used by hundreds of millions of users in the form of HTTPS.

Regarding client-side PKI one of the biggest problem is that there is no consensus what a certificate is supposed to vouch for.

This is my year 2005-2008 "prophecy" for what it is worth:

Commercial client-side PKI will consist of "ID-card" like TTP- issued certficates. The CAs will consist of 2-5 networks of banks. The reason that the banks will take this market is that they must anyway have a registered relation with their clients which means that the RA-part is "for free". No one else can match this!

Now, to another interesting part: These certificates will neither vouch for the individual as being employed somewhere, nor being authorized to do something particular, just telling that this is John Doe with customer ID 4545445 isued by MegaBank of Galaxy Trust Network.

Why this: Beacuse such a certficate can be used for any purpose in the communication with an individual's own trusted parties. Trusted parties means your bank, your employers, some authorities. The reason to use ID-card-like PKI's with untrusted parties like Internet-merchants seems like an unlikely idea for many reasons.

This is BTW also based on the idea that the proxy-way of PKI-ing (like 3D secure) will be the dominating way to do things like credit-card payments and B2B-purchasing.

And who is paying: The customer as they already do for passports, driver licenses etc. $10-25/Year is a rough estimation.

And where will we keep it: In our PDA's and mobil phones. The card-makers have screwed up things by making properietary solutions which means that they are "toasted" as far as I can see.

What will never happen on a grand scale is: Every company issues certficates to their employees that in turn use these for interaction with external business parties. They will always interact through a proxy (or "business system" as it is usually known as). As in:

http://web.archive.org/web/*/http://www.x-obi.com/OBI400/GEA-B2B-PKI.ppt

cheers,
Anders


ALARMED ... Only Mostly Dead ... RIP PKI ... part II

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/30/2002 05:31 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>,
    sberinato@xxxxxxxx, sscalet@xxxxxxxx, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI ... part II
as an aside, there was booth at cardtech/securetech a couple weeks ago in new orleans for a hardware token that just did ecdsa (fips186-2) digital signatures w/o any certificates..

earlier this week source-forge accepted the statement for package of server side fips186-2 signature authentications software and the package should be on source forge shortly

http://www.sourceforge.net/

a possible issue for financial institutions, once they have "already done the RA-part for free" ... would they then issue certificates that have design point of both 1) offline environment and 2) for people with no prior business relationship .... or would they acknowledge that the world has significantly moved towards an online, real-time environment (like they have for payment transactions) and any significant need for the old offline design point that certificates were invented for has possibly passed on by.

anders.rundgren@xxxxxxxx on 5/30/2002 1:40 am wrote:
I think I'm less alarmed. As noted by Chuck Wade, PKI is used by hundreds of millions of users in the form of HTTPS.

Regarding client-side PKI one of the biggest problem is that there is no consensus what a certificate is supposed to vouch for.

This is my year 2005-2008 "prophecy" for what it is worth:

Commercial client-side PKI will consist of "ID-card" like TTP- issued certficates. The CAs will consist of 2-5 networks of banks. The reason that the banks will take this market is that they must anyway have a registered relation with their clients which means that the RA-part is "for free". No one else can match this!

Now, to another interesting part: These certificates will neither vouch for the individual as being employed somewhere, nor being authorized to do something particular, just telling that this is John Doe with customer ID 4545445 isued by MegaBank of Galaxy Trust Network.

Why this: Beacuse such a certficate can be used for any purpose in the communication with an individual's own trusted parties. Trusted parties means your bank, your employers, some authorities. The reason to use ID-card-like PKI's with untrusted parties like Internet-merchants seems like an unlikely idea for many reasons.

This is BTW also based on the idea that the proxy-way of PKI-ing (like 3D secure) will be the dominating way to do things like credit-card payments and B2B-purchasing.

And who is paying: The customer as they already do for passports, driver licenses etc. $10-25/Year is a rough estimation.

And where will we keep it: In our PDA's and mobil phones. The card-makers have screwed up things by making properietary solutions which means that they are "toasted" as far as I can see.

What will never happen on a grand scale is: Every company issues certficates to their employees that in turn use these for interaction with external business parties. They will always interact through a proxy (or "business system" as it is usually known as). As in:


http://www.x-obi.com/OBI400/GEA-B2B-PKI.ppt

cheers,
Anders


ALARMED ... Only Mostly Dead ... RIP PKI .. addenda

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/30/2002 07:53 PM
To: Chuck Wade <chuck@xxxxxxxx>
cc: Internet Payments <internet-payments@xxxxxxxx>
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
there are two parts of certificate design point (not just one)

1) no prior relationship (i.e. except in the introductory stage, not applicable for financial infrastructure)

2) offline (not applicable in the online payment infrastructure)

all things considered somebody that is being paid would prefer an online, realtime notification that the financial institution says that the money is available and is being transferred (i.e. if they get their money they don't actually need to know who you are .... which is the EU directive that point-of-sale electronic financial transactions are as anonymous as case). it is only when things regress to pre-1970 technology into an offline world that a poor 2nd choice is to know who you are ... as opposed do i already have the money.

another payment scenario from pre-1970.. are corporate checks that had signing limits printed on the checks (somewhat analogious to certificates of a particular kind). they discovered that fraud was happening by people signing 200 $5000 checks for $1m ... aka no real time aggregation. The transition was made from signing check limits to real-time aggregation. given an online infrastructure .... is it better to have transaction built around stale, static data ... or transaction built around real-time aggregation information.

The design point of "trusted" stale, static data (aka some sort of credential or certificate) in an offline system is better than having no information aka that was the original invention justification for certificates .... not having an online system to get real-time, up-to-date transaction aggregation information (if you are in a pre-1970 technology situation ... with offline payment transaction ... then some sort of certificate is better than not having anything). However, given that there possibly is the availability of a post-1970 online technology ... that it would appear to be a better choice to go with an online transaction as opposed to an offline transaction paradigm.

Now some of the past payment related certificates have been in the 1k to 4k byte range. There is significant portion of payment transaction that currently operate with 80-100 bytes. The x9.59 mapping to ISO 85838 networks has one the order of 80 byte payload increase ... 42byte ecdsa, fips186-2 signature plus misc. other information for increased integrity. I believe that some of the x9 sixty-something certificate compression is talking about a simple straight-foward something on the order of 300 bytes for a ecc (163-bit) public key and a 42 byte ecdsa signature. note however, that the whole design point for such a certificate is to be able to authenticate an offline transaction ... since the certificate is redundant and superfluous in online transactions processed by the customer's financial institution. There is some push back on the unique information in the x9.59 addenda since it almost doubles the size of existing payment transaction. The pushback is even worse when considering an optimized, compressed, 300-byte ecc certificate that is totally redundant and superfluous and servces no valid business purpose.

Note however, that if such a certificate were to contain any identification information and it was viewed by any but the customer's financial institution then it would be in violation of the EU's anonymous directive. Now, the financial institution doesn't need the certificate ... since it already has all the information. The merchant doesn't need know anything from the certificate if there is a realtime online transaction that gives a real-time commitment from the financial institution that 1) it is a valid transaction from 2) a valid customer account, 3) there is sufficient funds, and 4) the bank is transferring the funds.

Part of this is that it is post-1970, there is significant world-wide coverage for doing online transaction, that being able to do online, real-time, payment authorization taken into account real-time account transaction aggregated information .... is of higher quality than an offline transaction with stale, static information possibly year or more old.

with regard to legacy systems (including stove-pipe legacy systems), i made the statement that there is a much larger upfront cost to integrate public key support into existing production system ... as compared to the upfront cost to deploy a brand new server with new operation (especially if it is a simple SSL-like certificate manufacturing ... as opposed to full-blown PKI).

The problems that have cropped up in financial consumer certificate issuing (whether PKI or simple certificate issuing) ... is that there is the issue of keeping a customer database. that customer database then has to eventually have all the customer activity support as the "real" production customer account database operation. The presentation made at NISSC (previously mentioned) calculated that the cross-over point for financial institutions between the upfront cost reduction of doing a separate PKI operation ... as opposed to modifying the stove-pipe legacy stuff for public key authentication was somewhere around 5 percent of the account base. If financial infrastructure was looking at supporting less then five percent of its customer base with public key authentication ... then a separate PKI "stove-pipe" was probably cheaper. If the financial infrastructure was looking at supporting public key authentication for more than about five percent of its customer base ... then it was probably cheaper to modify the existing stove-pipes (than it was to effectively create a new and separate stove-pipe for PKI).

my statement has always been that a trusted stale, static certificate/credential is always better than nothing when you are in an offline world and don't have access to real-time, online information. However, for almost anything of importance or value ... given the opportunity of doing either 1) a real-time online transaction or 2) doing a offline, delayed transaction based on stale, static certificate ... which would one choose.

Given a infrastructure that is in general moving towards online, real-time .... the multiple legacy stove-pipe situation would be aggravated with yet another (PKI) stove-pipe (in other than very early technology exploratory pilot stages)

Given some infrastructure that is really an offline environment ... then it is obvious that a trusted, stale, static credential/certificate is better than nothing at all. The statement that certificates are redundant and superfluous in an online, realtime payment transaction infrastructures is in no intended to imply that they are totally useless and/or don't have application. They were specifically invented for offline environment for parties that have had no prior relationship/knowledge.

Something as an aside, the online payment infrastructure ... is in effect an online certification authority paradigm ... with realtime online ransactions as opposed to trusted stale, static credential/certificate offline paradigm. It turns out that the certificate issuing certification authorities actually make extensive use of this realtime online feature for some number of consumer/client certificates they issue. They effectively take a credit card in payment for the credential they issue ... and for the basic credential type with name and address use the name/address verification option of the realtime credit card transaction as the means of checking the name and address. There are some number of other web-based "certification" sites (some doing realtime transactions in lieu of stale, static credentials and others that issue a form of short-lived credentials ... possibly analogous to kerberos tokens) that also rely on the name/address verification option of the realtime credit card transaction as the means of checking name and address.

chuck@xxxxxxxx on 5/30/2002 8:25 am wrote:
Lynn,

You do put an interesting interpretation on things. A few points worth noting:

(1) Letters of credit are very much alive, today, having survived the invention of the telegraph, the telephone, and, so far, the invention of the Internet. They are in regular use for lots of global commerce activities. There are even electronic versions of letters of credit. Suffice it to say that there is still value in being able to extend one's business reputation (credit) beyond one's normal domain of operations.

(2) To put things in perspective, the primary contributors to the "onerous payload" in X.509 certificates are the public keys themselves. Next are the signature blocks of the issuers. Basic X.509 certificates do little more than provide the name of the subject of the certificate, the name of the issuer, and some basic management information, such as the starting and ending dates for when the cert is valid. Plastic mag-stripe credit cards actually carry a lot more information than do basic X.509 certs (although public keys are longer than credit card numbers). True, there are lots of optional fields and extensions in the X.509 standards, but even when these are used, they generally don't add that much bulk (unless someone really does stick the entire certificate practice statement into the cert). [Please, before you respond with a list of your favorite stats on cert size and hyperlinks to your voluminous archives, read on and recognize that none of this really matters until we better understand what we're trying to accomplish.]

(3) While it is true that you don't need a cert in the case where the issuer is the only party that will rely on the cert, this is not the typical case in most business situations. Even banks tend to have lots of stovepipe operations that have no good internal means for sharing information about customers and their reputations. Many other businesses are also comprised of multiple stovepipes. There may also be good reasons that the "Bank of England" (to cite your example) might issue a letter of credit to a customer based in England to help facilitate their opening of an account at the Bank of England branch in some other part of the world. If all the legacy systems in place today could effectively exchange information in a trustable fashion, then maybe such "inefficiencies" would not be required--but they don't!

It might also be worth noting that payments are between _payers_ and _payees_. Goverment Treasuries, banks and payment service providers merely facilitate the payment transactions and provide some "insurance" for a subset of the payment transactional risks. The key point is that payer-payee transactions are highly distributed in nature, and often between parties that have little or no transactional history with each other. Just a suggestion, but maybe we need to focus a bit more on how to facilitate payer-payee interactions and give payers and payees the tools they need to manage the very real risks they confront with every payment transaction.

The reason I provided some commentary on the editorial by Scott Berinato was that I'd like to see the industry dialogue move away from arguments about the machinery, and to more on-topic discussions of what it will take to create viable payment applications that can be conducted safely over the Internet. With a better understanding of user needs, system requirements, and appropriate architectures for new payment applications, perhaps we will then have the insight to intelligently evaluate what sorts of machinery will actually serve our purposes.

As I've already emphasized, the PKI approach is on the wrong path. But, if you'll forgive me for saying so, I contend that your approach is also not showing a great deal of promise these days. To be honest, only a narrow set of applications is served by a model where the issuer of public key credentials is also the only relying party. This might work for some highly centralized application models with rigid constraints on the relationships between the players. It is, perhaps, even a good model for extending some legacy systems, especially where closed protocols and networks are used.

Personally, I think it is a good idea to look at how new payment applications can leverage, and even extend, legacy payments infrastructure. On the other hand, I think it would be a mistake to continue the practice of stamping out new payment applications and innovative approaches for the sake of protecting existing payment system franchises that are protected by closed systems designs and technological constraints from the 70s and 80s. But that's just one man's opinion.

Regards...
--
...Chuck Wade
   Consultant, Internet Security and Financial Services
+1 508 625-1137  Office Phone/Voice Mail
+1 309 422-9871  Fax Service


ALARMED ... Only Mostly Dead ... RIP PKI ... part II

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
... note misc spellchecking, formating, finger fumble cleanups
From: Lynn Wheeler
Date: 05/31/2002 08:35 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "internet-payments" <internet-payments@xxxxxxxx>,
     sberinato@xxxxxxxx, sscalet@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI ... part II
of course it is possible to use stale, static credential/certificates for both online and offline transctions. The point is that stale, static credential/certificates are a design point for offline transactions between parties that.have no previous knowledge/relationship ... being better than the alternative ... nothing. (payment infraustructure is used to having risk management built around real-time aggregated information , why would they revert to an offline paradigm model for payments with stale, static infromation ... it is like dropping back into the dark ages).

Given any transaction involving something of importance or value ... given two equally available paradigm alternatives: online and offline ... why would anybody choose to have stale, static information when they could have real-time, uptodate, aggregated information (current account balance and actual funds available for payment transaction)? The choice of an offline paradigm with stale, static credentials/certificates presumbly would only be made when there was no choice for an online paradigm alternative. It is like old fashion business signing limit checks for fraud management ... it is a stale, static credential ... it is better than no limit at all ... but not as good as real-time, aggregated information for a payment transaction giving actual funds available for current transaction.

Yes a financial institution could sell a consumer a stale, static certificate so that customer could use it for offline transactions with somebody that they previously didn't know or previously didn't have a business relationship with .... or they might even be given a free certificate at some public-key RA-registration event. However, given an infrastructure that is partially already online, realtime, would they want to throw away the current online paradigm and revert to offline?

There are portions of the infrastructure that is not already online, realtime ... but mainly because it is non-electronic. The question is if the remaining portions of the payment infrastructure were to start migrating to electronic ... what would be the portions of those remaining non-electronic payment infrastructures that would migrate to electronic but offline vis-a-vis electronic and online. The stale, static credential is a solution for the electronic and offline design point. They are redundant and superfluous in the scenario for electronic, online, real-time transaction that involves aggregated information (aka current funds available or account balance, i.e. an account balance represents aggregated information in the sense it is the summary of all the account deposits minus all the account debits that can be occuring in real time)

Note however, that more and more of the world seems to be moving rapidly to electronic and online (especially with the aggresive wireless activity) . stale, static credentials are redundant and superfluous in the online, realtime world between parties that have previous relationship (like financial institutions and their customers).

At least in a couple of cases, the stale, static credentials appeared to have actually resulted in an offline payment solution because it didn't appear that it was reasonable to carry digitally authenticated transaction on the online payment network because of the onerous payload represented by the stale, static credentials themselves. It was then possible to show that the credentials were just a stale, static read-only copy of a subset of the information on file in the account record. It then became trivially obvious that returning a copy of stale, static information to a point that had the original of the full, up-to-date information was a superfluous activity.

So, back to a financial institution selling a customer a stale, static credential. It is possible. There is a need for stale, static credentials in the original design point for such credentials .... electronic, offline between parties that have had no previous business relationship.

Note however, just because a financial institution has sold a customer a stale, static credential ... so that customer can use it to perform offline electronic transactions with entities that customer previously had not knowledge .... doesn't mean that the financial institution should revert an online, real-time payment infrastructure to stale, static offline operation and loose important risk management characteristics of having real-time aggregated information. Furthermore, just because an organization wants to get off an online system that uses userids and passwords and go to a public key operation ... doesn't mean that they have to revert to an offline system with stale, static credentials.

For instance m'soft 2000, most unix'es and mainframes provide for Kerberos security access control. The draft pk-init document that defines the use of digital signature authentication to a kerberos environment specifies (in effect) that the digital signature can be authenticated either from an offline,stale, static credential or from an online userid database where the public key has been registered in lieu of a password.

Problem with userid/password being addressed with digital signature authentication doesn't automagically equate digital signature with offline, stale, static credentials. A digital signature authentication environment can be either online or offline paradigm. There can be perfectly valid reasons why somebody might want to move from an online userid/password paradigm to a offline digital signature paradigm using offline, stale, static credential/certificates. On the other hand there might also be reasons why an operation might want to move from an online userid/password paradigm to an online userid/publickey paradigm.

In prior note about existing web-based certification authorities doing real-time operation ... rather than providing a stale, static credential to you that you can present to others ... there are current web-base certification authorities that are sending real-time information to the business operations certifying the information. This is model analogous to current real-time payment network. These web-based certification authorities seem to be fairly active and doing a large business. It also appears to be an attractive business model ... since they are charging these other businesses on a per transaction basis ... as opposed to charging the customer up front for a stale, static credential.

FSTC (the organization currently hosting this payment mailing list) has seriously looked at this business model of doing real-time transactional certification within their FAST (financially authenticated secure transaction) project. The offline certification authority model has the certification authority selling the customer a stale, static credntial so that customer can do business with some other entity. The online certification authority model has real-time certification transactions occuring directly with the business that the customer is dealing with (and directly charging that business rather than the customer).

At 100,000 feet this is in effect the current online payment infrastructure model ...... where the attribute/characteristic being certified is the ability to pay based on the current instantaneous account balance. The FAST project is all about extending the real-time certification transaction of the payment business to other attributes. One of the most commonly mentioned attribute would be age ... however in the real-time transaction certification (as opposed to the offline paradigm with stale, static credentials) a business might ask the financial institution something about the customers age .... like over 21, under 14, at least 18, over 55, etc. The financial institution just send back a certified real-time answer ... basically yes/no.

There is no stale, static credential sold to the customer. Furthermore, this is similar to the major business of a fair number of the existing web-based real-time certification authorities. They are making a booming business doing real-time age certification transactions (as opposed to selling stale, static credentials to the customer ... they are doing real-time transaction charging to the businesses that the customer is dealing with).

A closed offline certification operation are the relying-party-only certificates issued in the past by financial institutions, in part to avoid including privacy information in a certificate. An open offline certification operation can be the traditional X.509 identify certificates that have been the object of standardization for at least the past ten years.

A open online certificatinon operation can be the current online debit/credit/atm payment operation ... even tho it currently doesn't use digital signatures or public key ... it is still an open, online certification operation (and x9.59 could extend it to an open online certification operation with digital signatures and public key). Another open, online certification would be the current online web-based operations that do things like certify age (again w/o using digital signatures). A proposal for an open, online certification would be the FSTC FAST project that has the option of being done with digital signatures.

Kerberos can be deployed as either open or closed online certification operation ... depending on what the cross-domain certification agreements are. The issue of whether Kerberos is deployed as open or closed is pretty independent of its authentication procedure. It will provide cross-domain open online certification independent of using userid/password for authentication. The pk-init internet standards draft for Kerberos digital signature authentication is independent of whether kerberos is deployed for open online certification operation or closed online certification operation. Also, whether the public key for digital signature authentication is extracted from a certificate or from the Kerberos userid database is independent of whether kerberos is configured for open or closed online certification operation.

For various technical reasons associated with the offline design point, certificates infastructure have had to equate the digital signature authentication and the information being certified into a single operation. Just because they are packaged that way in a certificate doesn't mean that they are equivalent in a business sense. In a business sense

offline/online
authentication mechanism
open/closed
are all independent operations (even tho certificates have chosen to package them together).



However, it is a totally false to claim that just because something doesn't use public key from a certificate ... that it is a closed certification process. The attributes of open/close, method of authentication, and offline/online are all indepentent business characteristics (regardless of how some particular certification operation has chosen to implement them).

There is online payment network which is an open certification system that just currently doesn't happen to use digital signature authentication ... but does realtime online payment certification transactions (as opposed to offline stale, static credential certificates)

There are online web-based age open certification that do realtime online age certification transactions that happen to currently use userid/password (again not offline, stale, static credential certificates).

There is the FSTC FAST project that has looked at extending the open online payment certification transactions to attributes other than ability to pay

The is X9.59 digital signature authentication standard that extends the existing online payment network realtime transaction to digital signature authentication. It is possible to apply the X9.59 approach for payment authentication to the open online FSTC FAST extensions of doing real-time certification of attributes other than payment (generalizes open, online attribute certification with digital signature authentication w/o certificates)

There is Kerberos that does online certification that can be configured for either open or closed (depending on the cross-domain kerberos aggreements). Kerberos is currently userid/password based for authentication (which is independent of whether it has open or close attribute). PK-init draft is extending kerberos standard to also support digital signature authentication .... allowing both certificate based digital signature authentication and userid/publickey database based digital signature authentication. The issue of userid/password authentication. certificate-based digital signature authentication or userid/publickey database digital signature authentication are orthogonal to whether kerberos online certification has been configured for open or closed.

anders.rundgren@xxxxxxxx on 5/31/2002 2:02 am wrote:

>a possible issue for financial institutions, once they have "already done
>the RA-part for free" ... would they then issue certificates that have
>design point of both 1) offline environment and 2) for people with no prior
>business relationship .... or would they acknowledge that the world has
>significantly moved towards an online, real-time environment (like they
>have for payment transactions) and any significant need for the old offline
>design point that certificates were invented for has possibly passed on by.

Lynn,

I would put it in another way. Enterprises want to get away from user-IDs and passwords. If their employees once register in the PA-system using an FI-issued identity in the form of a certficate, companies do not have to jump into the CA-business and employees get long-lived (renewable) static credentials that they can use for many puposes. That's worth $10-$25/y. When you leave a company your entry in the PA-system is simply deleted. There is nothing to revoke, take back etc. Such a PKI-resource can be used for both on-line and off-line operations.

When I wrote "the individual's own trusted parties" I referred to parties where you probably have a strong relationship with. But you could actually remotely sign-up for any kind of service using such a credential. The FI-issuer can under your command (using your PKI-credential), create a signed document that contains other data about yourself that the service may need to accept a new member. That may include finanicial statements, date-of-birth, gender, nationality, address, photo, or whatever they have registered on you. I.e. an attribute cerificate of some kind.

Non-certificate schemes OTOH, like the ones you are advocating for (AADS) are similar (I would say identical) to closed PKIs.

If we right now think that technological problems of various kinds is the major problem, I'm sure that the FUTURE battle will be about:

Open versus closed PKIs.

We apparently have different beliefs here and since at this stage we are really talking about "beliefs" rather than absolute truths, we just have to wait another 5 years or so to see what happends.

I'm personally trying to make the open PKI more practical as at least in a many-to-many, plug-and-play, B2B-environment, I cannot really see any viable alternative to open PKI. OBI Express, my "baby", is one of the first B2B standards-to-be that are entirely based on open PKI and digital signatures. When the new HW-crypto-box that IBM is beginning to put in standard low-end PCs, reaches servers as well, security can be in the same leage as for VPNs, but at 2-5% the cost of thoose.

cheers,
Anders
X-OBI


Royal Mail pulls plug on ViaCode digital certificate

From: Lynn Wheeler
Date: 05/31/2002 01:05 PM
To: internet-payments <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Royal Mail pulls plug on ViaCode digital certificate
http://www.theregister.co.uk/content/6/25496.html

ALARMED ... Only Mostly Dead ... RIP PKI ... part III

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/31/2002 02:36 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>,
    sberinato@xxxxxxxx, sscalet@xxxxxxxx, epay@xxxxxxxx
Subject: Re: ALARMED ... Only Mostly Dead ... RIP PKI ... part III
oh, trivial example of the online certification vis-a-vis offline certification by financial institutions for say employment.

In the online certification (using the FSTC FAST model), the application signs a message containing their name, address, public key, financial institution, account no ... and whatever other information the applicant is asserting ... plus the employer and current date/time. The employer sends it off to the financial institution ... the financial institutions cross-checks the asserted information (note that XML tags would be really helpful for automating this) and sends back a certification yes/no as to the asserted information. the bank charges the employer for the online certification. the scenario is that the asserted information is tailored specifically to the type of transaction and to maybe what the bank is willing to deal with. Note that in this scenario ... the public key is just another piece of asserted information. The bank looks at the signed request ... and validates my signature and each individual piece of asserted information and returns a realtime, online, dynamic, up-to-date, non-stale yes/no response as to the accuracy of the asserted information.

Now in the case of a generalized offline certification using certificates .... a year ago my bank issued me a certificate with all possible asserted information that covers all possible scenarios that might ever possible arise in the future. I might make different types of assertions to different kinds of entities that i need certified ... a one-size-fits-all kind of certificate needing to have all possible types of information that i might ever need to be certified (names, addresses, age, history, balance, citizenship, etc, etc). The other choice is i get a couple dozen different certificates certified with different combinations of information covering all possible situations that might ever possible arise in the future.

A third choice is i get a dozen very specific certificates ... each certificate specific with one and only one piece of certified information ... i keep all such certificates around ... and when i want to assert a specific set or combination of information .... i present the appropriate combination of certificates.

Now, however I do it, I'm still presenting stale, static certified certificate information. There is some high probability for any event of any importance and/or value ... the entity I'm dealing with is going to still want to make a real-time validation of at least some piece of the information (i.e. call up the bank to see if anything has changed in the last 12 months). So even in the case of the offline certification operation, except for matters of no-importance and no-value ... the business entity is probably going to make a real-time check as to the timeliness of at least some of the asserted/certified (stale, static) information. The financial institution still gets their FSTC FAST realtime, online transaction which they can directly charge on a transaction basis as to the accuracy of the asserted information being certified.




Now as to the proxy PKI ... this can be considered the online certification in disquise. I make some assertions (like in the online payment system ... that I assert to a merchant that I pay for the operation). The merchant accepts the assertion and sends it to the appropriate online certification authority (i.e. issuing financial institution) which does a real-time certification of the assertion and returns the certification to the merchant. The slight difference is that I send the assertion directly to the proxy PKI w/o it having to pass thru the merchant first. Now, in previous discussions it has been pointed out that a online, realtime certification authority can provide realtime certification.

This realtime certification (say a automated purchasing agent that verifies that I actually have budget and authority to order something) does its check before certifying it .... say in a B-to-B environment.

Now the B-to-B environment can either be offline certification ... with digital signatures and certificates so that B-to-B entities with no previous relationship can directly deal with each other ... or it can be with digital signatures and accounts. The account mechanism is how things are done today .... business first establish a business relationship and create account records that represent that business relationship. As part of that business relationship they register various kinds of information in their account records ... which can be maintained in real-time (active, in default, etc). One of the kinds of information that can be put in account records is a public key.

The other alternative is that in the b-to-b environment there is no prior business relationship established ... sort of a hit-and-run, one-of-a-kind business transaction ... this can be either addressed with

1) offline certificate credentials with stale, static information certified by trusted financial institition

2) online certification where each business checks with trusted financial institution (as in the employee applicant scenario given earlier).

also:
http://www.garlic.com/~lynn/aadsm11.htm#40

PKI: Only Mostly Dead

Refed: **, - **, - **
From: Lynn Wheeler
Date: 06/10/2002 04:58 AM
To: pgut001@xxxxxxxx (Peter Gutmann)
cc: cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
nobody@xxxxxxxx, pgut001@xxxxxxxx,
Subject: Re:  PKI: Only Mostly Dead
I think there is even less "I" than most people suspect. I've recently taken to some manual sampling of SSL domain name server certificates ... and finding certificates that have expired ... but being accepted by several browsers that i've tested with (no complaints or fault indications).

there was thread in another forum where I observed that back when originally working on this payment/ecommerce thing for this small client/server startup that had invented these things called SSL & HTTPS ... my wife and I had to go around to various certificate manufactures with regard to some due diligence activity. I think w/o exception that they all made some comment about the "PK" being technical ... and the "I" being service ... and providing "service" is an extremely hard thing to do (and they hadn't anticipated how really hard it is).

some past ssl domain name certificate threads:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

As i've observed previously there are a number of ways that the technical stuff for "PK" can be done w/o it having to equate to (capital) PKI ... some recent threads on this subject:
http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#32 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#34 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#35 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aadsm11.htm#18 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#19 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#20 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#21 IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#22 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
http://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D Secure
http://www.garlic.com/~lynn/aadsm11.htm#32 ALARMED ... Only Mostly Dead ... RIP PKI
http://www.garlic.com/~lynn/aadsm11.htm#33 ALARMED ... Only Mostly Dead ... RIP PKI
http://www.garlic.com/~lynn/aadsm11.htm#34 ALARMED ... Only Mostly Dead ... RIP PKI
http://www.garlic.com/~lynn/aadsm11.htm#35 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#36 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
http://www.garlic.com/~lynn/aadsm11.htm#37 ALARMED ... Only Mostly Dead ... RIP PKI
http://www.garlic.com/~lynn/aadsm11.htm#38 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III

pgut001@xxxxxxxx at 6/1/2002 2:18am wrote:

>Peter Gutmann should be declared an international resource.

Thankyou Nobody. You should have found the e-gold in your acount by now :-).


>Only one little thing mars this picture. PKI IS A TREMENDOUS SUCCESS WHICH IS
>USED EVERY DAY BY MILLIONS OF PEOPLE. Of course this is in reference to the
>use of public key certificates to secure ecommerce web sites. Every one of
>those https connections is secured by an X.509 certificate infrastructure.
>That's PKI.

"Opinion is divided on the subject" -- Captain Rum, Blackadder, "Potato".

The use with SSL is what Anne|Lynn Wheeler refer to as certificate manufacturing (marvellous term). You send the CA (and lets face it, that's going to be Verisign) your name and credit card number, and get back a cert. It's just an expensive way of doing authenticated DNS lookups with a ttl of one year. Plenty of PK, precious little I.


>The truth is that we are surrounded by globally unique identifiers and we use
>them every day. URLs, email addresses, DNS host names, Freenet selection
>keys, ICQ numbers, MojoIDs, all of these are globally unique!
>"pgut001@xxxxxxxx" is a globally unique name; you can use that
>address from anywhere in the world and it will get to the same mailbox.

You can play with semantics here and claim the exact opposite. All of the cases you've cited are actually examples of global distinguisher + locally unique name. For example the value 1234567890 taken in isolation could be anything from my ICQ number to my shoe size in kilo-angstroms, but if you view it as the pair { <ICQ domain>, <locally unique number> } then it makes sense (disclaimer: I have no idea whether that's either a valid ICQ number or my shoe size in kilo-angstroms).

(This is very much a philosophical issue. Someone on ietf-pkix a year or two back tried to claim that X.500 DNs must be a Good Thing because RFC 822 email address and DNS names and whatnot are hierarchical like DNs and therefore can't be bad. I would suspect that most people view them as just dumb text strings rather than a hierarchically structured set of attributes like a DN. The debate sort of fizzled out when no-one could agree on a particular view).

I think the unified view is that what you need for a cert is a global distinguisher and a locally meaningful name, rather than some complex hierarchical thing which tries to be universally meaningful. Frequently the distinguisher is implied (eg with DNS names, email addresses, "for use within XYZ Copy only", etc), and the definition of "local" really means "local to the domain specified in the global distinguisher". I'm not sure whether I can easily fit all that into the paper without getting too philosophical - it was really meant as a guide for users of PKI technology.

Peter.


Web site exposes credit card fraud

From: Lynn Wheeler
Date: 06/27/2002 06:08 AM
To: Internet-Payments List <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Web site exposes credit card fraud

http://www.cnn.com/2002/TECH/internet/06/26/identity.theft.ap/index.html

Web site exposes credit card fraud

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 06/27/2002 06:49 AM
To: Internet-Payments List <internet-payments@xxxxxxxx>, epay@xxxxxxxx
Subject: Re: Web site exposes credit card fraud
oh yes ... misc. past threads in this area:
http://www.garlic.com/~lynn/subtopic.html#fraud

and specific thread on security proportional to risk specifically with respect to cc nos.
http://www.garlic.com/~lynn/aepay10.htm#20 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#24 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#25 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#28 Security Proportional to Risk (was: IBM Mainframe at home)

lynn.wheeler@xxxxxxxx on 6/27/2002 8:08 am wrote

http://www.cnn.com/2002/TECH/internet/06/26/identity.theft.ap/index.html


Giuliani: ID cards won't curb freedoms

Refed: **, - **, - **
From: Lynn Wheeler
Date: 06/28/2002 06:20 AM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: cryptography@xxxxxxxx,
    Digital Bearer Settlement List <dbs@xxxxxxxx>
Subject: Re: Giuliani: ID cards won't curb freedoms
i was in the audience ... and i'm pretty sure that the id-card subject was only in short response to question asked from the audience. this was the e-gov conference (dan greenwood was on the podium the day before giving out awards from mit for web-stuff excellence).

cards were mentioned a few of times in various conference sessions ... the primary focus of attendees was generally terrorists or other disasters ... with lot of specific focus on IT related aspects (helping manage the incident and/or as points of vulnerabilities) .... this was something of a dataprocessing event with it professionals of one sort or another. sort of a straw poll ... i could guess that 2/3rds of the times that cards were brought up during sessions ... it was in the context of not working.

of course ... within the context of my aads chip strawman .... i have some opinion about that.

rah@xxxxxxxx on 6/26/2002 3:57 pm wrote:
http://news.com.com/2102-1017-939499.html


Giuliani: ID cards won't curb freedoms
By Margaret Kane
Staff Writer, CNET News.com
June 26, 2002, 9:00 AM PT
http://news.com.com/2100-1017-939499.html

WASHINGTON--U.S. citizens may need to carry national identification cards someday, but that doesn't need to translate into a loss of fundamental freedoms in the name of safety, former New York Mayor Rudolph Giuliani said Wednesday.

"We need a better way to properly ID people that's more effective (than current means). There's a trade-off we have to make between privacy and the protection of everybody...in society," said Giuliani, following a keynote speech at the E-Gov 2002 conference here. More than 10,000 people are attending the four-day conference, which concludes Thursday.

A national ID system has become a hot-button issue within the tech industry and nationally. Technology experts and privacy advocates have been debating the merits of national ID cards and other identification systems and trying to figure out how to make sure they wouldn't be abused.

Giuliani said ID cards do not necessarily equal a loss of freedom, adding that other democratic countries require citizens to carry ID cards.

"We have to separate fundamental freedoms...from those things that we had the luxury to do in the past," he said.

Giuliani's speech was met with standing ovations and flag waving from the crowd at the show, which included employees of federal, state and local governments. The conference here is being run jointly with one on "homeland security," reflecting a new focus from the technology world and the government of using IT for defense.

Giuliani discussed ways that technology aided him as mayor, including helping him handle the terrorist attacks of Sept. 11.

Before those attacks, Giuliani's best-known achievement had been lowering the city's crime rate, a feat he said was greatly helped by the use of technology to conduct daily monitoring of crime.

The city had previously analyzed crime statistics on a yearly basis, but he initiated a program that helped track crime at the precinct level on a daily basis and plotted that data on geographic and time bases to more efficiently deploy police officers.

Similar programs were used in the city's correctional facilities to help reduce violence at Riker's Island by 80 percent, he said.

Technology also helped open up the city to citizens, he said, making their lives easier. For instance, New York has put in place ways for citizens to use the Internet to pay parking tickets and apply for permits for everything from opening a restaurant to tackling new construction.

"One of the great complaints about government, certainly in New York City, was that it was unusable...and unmanageable," he said. "E-government is a way to change that."

Giuliani's Emergency Management System, created in 1996, used technological simulations to train for emergencies including terrorist attacks, fires and other crises, Giuliani said.

"I can't emphasize more how important that it is to prepare for the worst thing you can imagine," he said. "Using technology to try and play games for what might happen, even if they're not exactly right when the emergencies occur," is an important way to prepare.

Giuliani cautioned attendees to prepare for the unexpected but to remember that "life goes on."

"At home, we have to do everything we can to be better prepared," he said. "At the same time, we have to get people to relax and go about their daily lives."

Giuliani disagreed with the notion that the world is now a more dangerous place.

"It was as if a curtain was in front of us; we saw the world the way we wanted to see it. Now the curtain has been lifted, and we can see the world the way it really is," he said. "Having said that, and recognized that, even before doing anything about it we're safer."

Asked if he would be interested in becoming secretary of the proposed Department of Homeland Security, Giuliani said that he hadn't decided on his future but that the job that he really wanted was to become "general manager of the (New York) Yankees."


maximize best case, worst case, or average case? (TCPA)

From: Lynn Wheeler
Date: 06/30/2002 08:06 AM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: cryptography@xxxxxxxx,
Digital Bearer Settlement List <dbs@xxxxxxxx>, dcsb@xxxxxxxx
Subject: Re: maximize best case, worst case, or average case? (TCPA)
I remember looking at possibility at adding tamper resisistent hardware chip to PCs back in 83 or 84 time frame (aka the TCPA idea for PCs is going on at least 20 years old now). It was the first time I ran into embedding chip in a metal case that would create electrical discharge frying the chip if the container was breached.

Remember when applications came with their own copy-protection floppy disks? .... it was possible to build up a library of such disks .... requiring all sorts of remove, search, insert ... when switching from one application to another. They eventually disappeared ... but imagine if they had survived into the multitasking era .... when it would have been necessary to have multiple different copy protection floppy disks crammed into the same drive at the same time. The chip was suppose to provide an analog to the CPU serial number used for licensing software on mainframes .... dating at least from the original IBM 370s (store cpuid hardware instruction).

Some of the higher-end applications still do that with some form of dongle (originally in the serial port) that comes with the application .... it doesn't quite have the downside of trying to cram multiple floppies into the same drive concurrently; the serial port dongles allow for them to be inline cascaded ... and in theory still be able to use the serial port for other use at the same time.

i believe that there is some statistic some place about the UK and the US are really great .... that in those two countries the copyright piracy is estimated to only be 50 percent.

AADS Postings and Posting Index, next, previous - home