Misc AADS & X9.59 Discussions


AADS Postings and Posting Index,
next, previous - home



invoicing with PKI
invoicing with PKI
Is cryptography where security took the wrong branch?
Is cryptography where security took the wrong branch?
Is cryptography where security took the wrong branch?
Is cryptography where security took the wrong branch?
x9.59
Is cryptography where security took the wrong branch?
Is cryptography where security took the wrong branch?
Is cryptography where security took the wrong branch?
Is cryptography where security took the wrong branch?
Resolving an identifier into a meaning
Resolving an identifier into a meaning
Resolving an identifier into a meaning
Resolving an identifier into a meaning
Resolving an identifier into a meaning
End of the line for Ireland's dotcom star
New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
how simple is SSL? (Re: Monoculture)
Simple SSL/TLS - Some Questions
Simple SSL/TLS - Some Questions
Simple SSL/TLS - Some Questions
Trusting the Tools - was Re: Open Source
NCipher Takes Hardware Security To Network Level
Homeland Security chief mulls SEC cybersecurity filings
WYTM?
SSL, client certs, and MITM (was WYTM?)
SSL, client certs, and MITM (was WYTM?)
SSL, client certs, and MITM (was WYTM?)
SSL, client certs, and MITM (was WYTM?)
NSA Buys License for Certicom's Encryption Technology
Electronic Safety and Soundness: A Four Pillar Approach; Public Policy Issues
VS: On-line signature standards
VS: On-line signature standards
VS: On-line signature standards (slight addenda)
VS: On-line signature standards
VS: On-line signature standards
VS: On-line signature standards
FAQ: e-Signatures and Payments
FAQ: e-Signatures and Payments
FAQ: e-Signatures and Payments


invoicing with PKI

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 02 Sep 2003 15:02:50 -0600
To: Hadmut Danisch <hadmut@xxxxxxxx>
Subject: Re: invoicing with PKI
Cc: iang@xxxxxxxx, cryptography@xxxxxxxx
At 12:23 PM 9/1/2003 -0400, Ian Grigg wrote:
1. invoicing, contracting - no known instances
2. authentication and authorisation - SSL client
side certs deployed within organisations.
3. payments
4. channel security (SSL)
5. email (OpenPGP, S/MIME)


somewhat related thread in sci.crypt ... summary
https://www.garlic.com/~lynn/2003l.html#33 RSA vs AES
background
https://www.garlic.com/~lynn/2003l.html#24 RSA vs AES
https://www.garlic.com/~lynn/2003l.html#27 RSA vs AES
https://www.garlic.com/~lynn/2003l.html#28 RSA vs AES
https://www.garlic.com/~lynn/2003l.html#32 RSA vs AES

when we were working with small client/server startup for payments
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

we coined the term certificate manufacturing as part of doing due diligence on various commercial CAs ... to distinguish from PKI.

we've also since claimed that proposal, effectively by SSL server certification business ... to have public keys registered as part of the domain name process goes a long way to both 1) improving the integrity of the domain name infrastructure and 2) provides basis for trusted, real-time public key distribution making SSL server certificates redundant and superfluous.
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

One of the big issues with identity x.509 certificates from the early 90s was the quandary with 1) overloading a certificate with huge amounts of privacy information (hoping that its use by unknown relying parties at some point in the future would find something in the certificate useful and 2) the extremely onerous privacy issues with the spraying of such privacy information all over the world. Somewhat as a result, financial infrastructures dropped back to relying-party-only certificates .... something that effectively contained only the public key and the account number.
https://www.garlic.com/~lynn/subpubkey.html#rpo
Somebody from Deutsche bank made a presentation in 1998 regarding having moved to relying-party-only certificates because of the enormous privacy and liability issues. However, since Duetsche bank had issued the certificate for the public key (and account), Duetsche bank already had the public key on file. There was actually nothing in the appended relying-party-only certificate that carried any information that Duetsche bank didn't already had on file (and the elimination of the requirement to append a certificate tended to remove a large payload penalty).

It was relatively trivial to show for financial transactions that relying-party-only certificates were redundant and superfluous (i.e. the financial institution already has all the information so there is no reason to tack a certificate on to the end of every transaction or communication with the bank).

The other issue ... somewhat highlighted by SET was that the payload penalty for certificates in the payment infrastructure was enormous ... a basic SET certificate possibly being two orders of magnitude larger than the basic payment message. As a result, SET typically was deployed for internet only operations with a gateway between the internet and the payment network performing the signature verification, stripping off the certificate and flagging the real payment transaction indicating that the signature had verified. First of all that violates one of the basic principles of end-to-end security. In fact, somebody from VISA presented some numbers in an ISO standards meetings about the transactions flowing through interchange with the "signature verified" flag set and they could prove that no digital signature technology was ever involved.

The financial standards x9a10 working group was given the requirement to preserve the integrity of the financial infrastructure for all electronic retail payments (aka ALL as in internet, non-internet, point-of-sale, face-to-face, non-face-to-face, debit, credit, ach, stored-value, etc ... i.e. ALL). The result was a digital signed transaction that was lightweight enough that it would operate in all environments and didn't require the enourmous payload penalty of an appended certificate:
https://www.garlic.com/~lynn/x959.html#x959

NACHA tested a certificate-less digitally signed debit transaction in their Internet trials:
https://www.garlic.com/~lynn/x959.html#aadsnacha

invoicing with PKI

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 03 Sep 2003 08:36:55 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
Subject: Re: invoicing with PKI
Cc: Hadmut Danisch <hadmut@xxxxxxxx>, cryptography@xxxxxxxx
Sender: owner-cryptography@xxxxxxxx
At 11:41 PM 9/2/2003 -0700, James A. Donald wrote:
True names is where security took the wrong branch. The entire PKI structure has been rejected.

x.509 identity certificates are business processes ... not a cryptography process. as I've mentioned elsewhere many of the institutions that looked at x.509 identity certificates in the early 90s had retrenched to relying-party-only certificates with just some sort of account number and public key. The problem of overloading a x.509 identity certificate with lots of privacy information turned out to be an enormous identity and liability problem. Part of the issue was creating a certificate at some time in the past and attempting to guess at what might be needed by various random relying-parties in the future ... led to overloading certificates with ever increasing privacy detail loaded. One of the content models was driver's license, name, address, date-of-birth. date-of-birth is an obvious identity theft vulnerability. The idea of randomly spraying your privacy detail all over the earth (attached to every electronic operation) turned out to be significant issues. Even just having your name attached to every electronic operation and sprayed all over the world represented a significant issue.

recent post in sci.crypt:
https://www.garlic.com/~lynn/2003l.html#33 RSA vs AES

and slightly related post (also from sci.crypt):
https://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model

Is cryptography where security took the wrong branch?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 07 Sep 2003 10:16:02 -0600
To: iang@xxxxxxxx
Subject: Re: Is cryptography where security took the wrong branch?
Cc: EKR <ekr@xxxxxxxx>, crypto <cryptography@xxxxxxxx>
At 03:01 AM 9/7/2003 -0400, Ian Grigg wrote:
Reputedly, chargeback rates and fees in the fringe industries - adult for example - can reach 50%. But, instead of denying those uses of the card - hygiene - issuers have encouraged it (...until recently. There is now a movement, over the last year, to withdraw service from the fringe industries, but, it is because of additional risks being added, not the risks of fraud or user loss. Visa is doing it, Mastercard is "waiting and seeing.")

a webhosting company presented some numbers at some standards meeting that they handled ten websites (all with monthly hits higher than the number one in the published monthly "hit" rankings) ... five were adult-type downloads and five were various kinds of (non-adult) software downloads. The adult-type charge backs were comparable to mainstream brick&mortar upscale retail outlets .... while the mainstream software downloads was on the order of fifty percent. It seemed that the people that download software are much more "fringe" than the types that download adult material (i believe they threw in some snide comments about the character of people that download software).

as I've mentioned before .... ipsec had been progressing very slowly in ietf for some time. in '94 ... you saw VPN being introduced at router working group (fall san jose meeting?) and introduction of SSL. both could be considered the domain of ipsec. Several of the router vendors didn't have processors capable of doing the crypto for VPN ... so you somewhat saw vaporware product announcements following the san jose meeting and VPN didn't make much progress until more router vendors had processors capable of handling the crypto load. the ipsec people seemed to eventually come to terms with vpn by referring to it as lightweight ipsec (so the vpn people got to refer to ipsec as heavyweight ipsec). also in 94 you started to see SSL deployment .... basically a transport level ipsec feature implemented by applications (could be considered because ipsec was having such a hard time progressing).

minor past refs:
https://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate
https://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/2003b.html#53 Microsoft worm affecting Automatic Teller Machines
https://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
https://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN
https://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec

what i remember from the time was that SSL was thought as handling all of the shopping experience .... not just the credit card part but the feedback was that doing everything thru SSL cut the thruput capacity by about a factor of five (or you could handle five times as much traffic on the same hardware not using SSL).. The result was rather than using SSL for all commercial activity ... it was cut back to just handling the credit card part.

Basically, SSL was being used for hiding the credit card number while in transit (over the internet). However, almost all the exploits have been from harvesting credit card files .... even when it would be possible to "sniff" non-encrypted credit card transmission. That issue is somewhat that you can be very targeted and quickly get possibly hundred thousand credit card numbers .... or you could put up a listening post and hope that you run across several a day (or maybe even an hour).

SET came out after SSL ... and made extensive use of public key operations. I reported a public key operation performance profile for SET within a couple weeks after the original specification ... which several people working on SET claimed to be one hundred times too slow. It was probably just wishful thinking on their part since when they had some running prototype ... the profile was within a couple percent of measured. An issue was that SET was at least an order of magnitude more resource intensive than SSL ... and the only thing it did was protect credit card information in transit; basically it was only addressing the same (credit card) threat model as SSL .... but with significantly more overhead (having possibly hundred times more PKI didn't actually make things more secure).

lots of past comments about what SSL does for credit card transactions (or anything else):
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

lots of recent comments in sci.crypt about eliminating certificates from SSL by collapsing the public key stuff into DNS:
https://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#44 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#46 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#50 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#51 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#52 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#53 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#54 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#55 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#57 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new)

Is cryptography where security took the wrong branch?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 07 Sep 2003 17:06:47 -0600
To: EKR <ekr@xxxxxxxx>
Subject: Re: Is cryptography where security took the wrong branch?
Cc: iang@xxxxxxxx, crypto <cryptography@xxxxxxxx>
At 09:44 AM 9/7/2003 -0700, Eric Rescorla wrote:
Incidentally, when designing SHTTP we envisioned that credit transactions would be done with signatures. I would say that the Netscape guys were right in believing that confidentiality for the CC number was good enough.

actually was supposedly no worse than the face-to-face world .... aka make the transit part secure ... so that the rest became the same as the physical world .... transactions go into big merchant file ... because there are several merchant related business processes that subsequently reference the transaction and number.

the problem was that there appear to be little or no fraud associated with threats against CC numbers in flight (with or w/o SSL), however the threat model was against the merchant credit card file and the numbers in the clear; it wasn't that the process was any different than the physical world, but the web merchants allowed the file to be accessible from the network (which didn't exist in the physical world).

the requirement given the x9a10 working group was to preserve the integrity of the financial infrastructure for all electronic retail payments (debit, credit, stored-value, ach, internet, non-internet, point-of-sale, etc). Turns out the internet threat profile wasn't so much data-in-flight .... but having the operation connected to the internet at all. X9.59 addressed most of that ... which neither ssl or set did .... and did it with just a single digital signaturee. misc. x9.59
https://www.garlic.com/~lynn/x959.html#x959

Is cryptography where security took the wrong branch?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 07 Sep 2003 17:19:24 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
Subject: Re: Is cryptography where security took the wrong branch?
Cc: crypto <cryptography@xxxxxxxx>
At 12:30 PM 9/7/2003 -0700, James A. Donald wrote:
To the extent that trust information is centrally handled, as it is handled by browsers, it will tend to be applied in ways that benefit the state and the central authority. Observe for example that today all individual certificates must be linked to one's true name and social security number if it is to receive default acceptance, and analogously for corporate certificates.

in the case of SSL domain name certificate .... for both domain name infrastructure and CA/PKI .... it is a case of authenticating that the web site you think you are talking to is really the web site you are talking to. The business issue is that the domain name registration and the CA/PKI are disjoint business operations and the domain name registration didn't provide for a really good authentication mechanism. As a result when getting a certificate request, the CA/PKI has to check with the domain name infrastructure .... map their information out to an external world identification, and then map the entity making the certificate request out to the same external world identification.

Out of all this, there is somewhat a request from the CA/PKI industry that a public key be registered as part of domain name registration (no certificate, just a public key registration). Then SSL domain name certificate requests coming into a CA/PKI can be digitally signed, the CA/PKI can retrieve the authoritative authentication public key (for the domain name ownership) from the domain name infrastructure and authenticate the request .... eliminating all the identification gorp (and also done w/o the use of certificates).

misc. additional recent musings:
https://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new)

Is cryptography where security took the wrong branch?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 09 Sep 2003 09:50:47 -0600
To: "Joseph Ashwood" <ashwood@xxxxxxxx>
Subject: Re: Is cryptography where security took the wrong branch?
Cc: <cryptography@xxxxxxxx>
At 04:25 PM 9/8/2003 -0700, Joseph Ashwood wrote:
Actually they do target very different aspects. SET, 3D-Secure, and any other similar have a different target then SSL. To understand this it is important to realize that instead of the usual view of two-party transactions, credit card transactions actually take 3 parties; Issuer, Seller, and Buyer. SSL covers the Seller-Buyer communication, and can also be applied to the Seller-Issuer communication, but on a transaction basis it offers nothing for the Issuer-Buyer (the important one for minimizing costs for the Issuer).

actually, physical credit card ... is a number of pair-wise communications .... card-holder to merchant terminal ... merchant terminal to merchant acquirer, merchant acquirer to interchange, interchange to issuer (credit card model is sometimes referred to as the 4-corner box .... with interchange trying to be transparent in the acquirer to issuer communication).

original electronic commerce with the netscape commerce server ... had SSL for the shopping experience ... with the credit card done at the end. The mall version of the commerce server had dedicated leased line directly to merchant acquirer. The wider used commerce server had a SSL connection from the commerce server to the payment gateway (which then interfaced to the merchant acquirer) ... effectively emulating the real world (two pair-wise communcations).
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

In the real-world .... SSL use got cut-back to only handling the credit card part of the transaction ... and not being used for the rest of the shopping experience.

In any case, the SSL flows exactly emulate the physical world (effectively the front side of the virtual POS running at the merchant website ... and the backside of the virtual POS to the acquirer) . ... modulo previous comment that the merchant transaction file in the physical world wasn't accessible via the internet (even tho it directly doesn't show up in the flows). The major exploits haven't been in the transaction flow part of the operation .... but in the business mechanics .... the major exploits have been harvesting the merchant transaction file. Neither SSL, nor SET have countermeasure against the major exploit (harvesting the merchant transaction file). Both SSL and SET hid the credit card number while in transit.

SET had all this other certificates and PKI gorp ... that significantly increased the crypto-related burden ( much more so than SSL). In theory, SET had an opportunity for end-to-end authentication .... but even a single certificate represented on the order of two-orders of magnitude bloat increase for the payload in the standard payment network (aka a single PKI certificate tends to be one hundred times larger than the typical, base payment transaction). The SET burden was orders of magnitude worse than the SSL burden. This, in part is what gave way to the SET payment gateway .... all the PKI gorp would occur at the SET payment gateway ....then all SET related information would be thown away, a standard 8583/x9.15 transaction created .... with an additional flag indicating that digital signature authentication had been correctly performed ...and off it goes.

One of the VISA business people later gave a presentation at an ISO meeting about the number of 8583 transactions flowing thru the payment network with the SET-authenticated flag set ....but they could prove that no PKI technology was even remotely possible for the transaction .... aka a slight issue of end-to-end security was violated. The important issue here was that the vision for SET ... was that if SET-authenticated transaction were involved ... the merchant eventually would be eligible for card-holder present discount rates ... rather than MOTO discount rates (aka having SET authentication was proposed as being as safe as a) card-holder present, b) card-preset, and c) track 1&2 readable). It was therefor in the interest of the merchant side of the business to tell the issuing side of the business that transactions were SET authenticated and the mrechant could get a much better discount rate).

The claim was that SET enormously increased the complexity, overhead, and payload processing ... while having little practical impact on the major vulnerabilities.

Out of all this ... the X9A10 standards working group was giving the requirement to preserve the integrity of the financial infrastructure for all retail payments. The result is X9.59 which addresses all the major exploits at both POS as well as internet (and not just credit, but debit, stored-value, ACH, etc ... as well).
https://www.garlic.com/~lynn/x959.html#x959

One of the things addressed by X9.59 was not the elimination of the ability to harvest the merchant transaction file ... but to make the account numbers in the merchant transaction file useless for fraud. slightly related discussion of the security proportional to risk and the vulnerability represented by the merchant transaction file
https://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
https://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???

misc. recent SET refs:
https://www.garlic.com/~lynn/aadsm15.htm#0 invoicing with PKI
https://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#3 Is cryptography where security took the wrong branch?

x9.59

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 09 Sep 2003 12:32:51 -0600
To: iang@xxxxxxxx
Subject: Re: x9.59
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>, cryptography@xxxxxxxx
At 01:44 PM 9/9/2003 -0400, Ian Grigg wrote:
Anne & Lynn Wheeler wrote:
> The result is X9.59 which addresses all the major
> exploits at both POS as well as internet (and not just
> credit, but debit, stored-value, ACH, etc ... as well).
> https://www.garlic.com/~lynn/x959.html#x959

Lynn,

Whatever happened to x9.59?

Also, is there a single short summary description of what x9.59 does? I don't mean a bucket full of links to plough through, I mean some sort of technical overview that wasn't approved by the marketing department.

iang


look at:
https://www.garlic.com/~lynn/x959.html#x959

and it has a pointer to the standards document at ANSI. I think there may be some discussion at the oct. x9 meeting about progressing x9.59 to ISO.

but slightly simpler description is the mapping of x9.59 to iso8583 (basically the credit/debit network standards protocol) at:
https://www.garlic.com/~lynn/8583flow.htm

the above lists the x9.59 elements and the iso 8583 elements .... and some mapping equivalence ... and how to carry the additional x9.59 values in an iso 8583 addenda field .... so you can achieve end-to-end authentication .... rather than truncated high integrity authentication at something like a boundary interface between the internet and the real payment infrastructure .... show how x9.59 can operate in all payment card processing environments (not just internet) and be able to provide x9.59 authentication on an end-to-end basis.

In this particular mapping between x9.59 and iso 8583 ... the original signed x9.59 object isn't carried end-to-end ... but there is a methodology defined for being able to reconstitute and verify the x9.59 object and the issuing financial institution.

The X9.59 standards document actual lists the ASN.1 encoding for the signing object (and therefor any reconstituted object) ... although there has been investigation into a x9.59 "version number" for XML specification. One of the original issues for XML encoding specification was that there was no deterministic encoding rules for XML .... allowing for an object to be mangled in transmission and then reconstituted for authentication. This is something that FSTC
http://www.fstc.org/
did for FSML .... the deterministic encoding rules to cover the scenario where a signed electronic check object was mangled for transmission thru the ACH network ... and then had to be reconstituted for signature authentication. Since then W3C has incorporated FSML into the xml signature specification work. some overview:.
https://web.archive.org/web/20010624034120/http://www.echeck.org/overview/echecktech.html

The problem wasn't whether XML or ASN.1 was better encoding method ... the issue was that given that the signed string of bits were mangled during transmission and had to be reconstituted, there had to be identical, deterministic encoding rules at both the signing end and the authentication end. This was very close to what was used in the NACHA AADS trials ... reference at:
https://www.garlic.com/~lynn/x959.html#aads

Although not in available document ... there was work mapping x9.59 directly to ACH network (the message formats in ACH are different than the message formats in the payment card networks .... actually many of the payment card networks ... both interchange and various acquiring networks ... have frequently proprietary differences from the ISO 8583 .... although there is lots of recent work to achieve convergence). These are primary electronic networks for retail payment transactions. There has also been some work mapping of x9.59 to wholesale networks, aka FEDWIRE, SWIFT, etc. The original X9.59 work was done in X9A, which deals with retail standards. In the past there has been some differentiation between the retail and wholesale financial networks under the assumption that the values (amount of money involved) in the wholesale transactions were a lot larger and therefor required much higher level of security which, in turn, should cost significantly more. However, I think we managed to demonstrate in X9.59 a level of integrity that is as high as anything required for wholesale transactions at the same time being able to achieve a cost that was acceptable for retail transactions.

To be effective ... the standard deployment just about needs a hardware token that can be trusted to house the private key and perform the signature operation. My joke from 5-6 years ago was that I was going to take a $500 mil-spec part and cost reduce by it two orders of magnitude while at the same time increasing the security ... and cut the time & power requirements so that it could meet the transit gate elapsed time requirements in a ISO 14443 contactless configuration (the transit constraint model was basically the octopus sony/mitsubishi card used in HK transit system)..
https://www.garlic.com/~lynn/x959.html#aadsstraw

I needled the chip module guys on this subject at a talk I gave two years ago at the intel developer's conference trusted platform track ... that it took them several years to iterate to nearly the same design point. The guy that headed it up ... claimed it was because I didn't have a committee of 200 people helping me .... a zip'ed copy of the presentation is listed a little lower in the AADS section of the web page (in front of the taxonomy/glossary section of the web page):
https://www.garlic.com/~lynn/x959.html#aads

Is cryptography where security took the wrong branch?

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 09 Sep 2003 14:24:00 -0600
To: <cryptography@xxxxxxxx>
Subject: Re: Is cryptography where security took the wrong branch?
At 05:19 PM 9/7/2003 -0600, Anne & Lynn Wheeler wrote:
Out of all this, there is somewhat a request from the CA/PKI industry that a public key be registered as part of domain name registration (no certificate, just a public key registration). Then SSL domain name certificate requests coming into a CA/PKI can be digitally signed, the CA/PKI can retrieve the authoritative authentication public key (for the domain name ownership) from the domain name infrastructure and authenticate the request .... eliminating all the identification gorp (and also done w/o the use of certificates).

misc. additional recent musings:
https://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new)


The "Database gaps make ID fraud easier, GAO says"
https://web.archive.org/web/20041217162347/http://www.gcn.com/vol1_no1/daily-updates/23446-1.html

is somewhat analogous to the SSL domain name certificate problem ... a primary purpose for existing is to authenticate that the website you think you are talking to is the website you are talking to.

The problem is that the domain name infrastructure has a database of domain name owners .... but no real good authentication infrastructure ... and the CA/PKI operations doing SSL domain name certifications are disjoint from the domain name infrastructure operations. As a result .... the CA/PKI industry has to treat requests for SSL domain name certificates effectively as if it was a random person walking in off the street ... and then they have to try and match up such seemingly random requests ... with what little bit of information that they can extract from the domain name infrastructure (seeing if they can establish an identity in the real world based on the DNS database information ... and see if that identity then can be matched against the identity of the entity requesting the certificate).

Adding a public key to the domain name infrastructure database as part of the domain name registration process .... then eliminates the requirement of trying to establishing corresponding identities in the real world ... and it just reduces to a question of authentication.

Of course, the bottom line is if the domain name infrastructure has a real-time database of public keys for authentication purposes .... in part for use by the CA/PKI industry for authenticating SSL domain name certificate requests .... for use in authentication operations .... the use of the domain name infrastructure's authentication public keys don't have to just be restricted to authentication use by the CA/PKI industry. In fact, domain name infrastructure authentication public keys could be used to effectively implement authentication operations that actually subsume the SSL domain name certificate authentication operations.

Is cryptography where security took the wrong branch?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 09 Sep 2003 19:24:46 -0600
To: "Joseph Ashwood" <ashwood@xxxxxxxx>
Subject: Re: Is cryptography where security took the wrong branch?
Cc: <cryptography@xxxxxxxx>
At 05:07 PM 9/9/2003 -0700, Joseph Ashwood wrote:
Now that the waters have been muddied (by several of us). My point was that 3D-Secure (and SET and whatever else comes along) covers a different position in the system than SSL does (or can). As such they do have a purpose, even though they may be horribly bloated and nearly non-functional. Visa at least seems to be supporting the 3D-Secure concept (they should, they developed it), and looks like anyone can grab the spec from

... while SET, 3d-secure, etc may have been designed for all sorts of reasons .... I guess my point was that w/o a adequately specified threat model .... for the primary vulnerabilities ... there turned out to be little effective difference between the use of SET and the use of SSL (regardless of what the designers may have original thot). Also technology adoption/uptake typically requires the transition to be less painful than the problem it is fixing. SSL was already in the market space ... so SET had to demonstrate that it was incrementally better (not effectively the "same as" for the major vulnerabilities) in order to justify its significantly more difficult and costly deployment.

The other issue that has been the bane of major PKI/certificate deployments (and I've repeatedly raised the issue) ... is that certificate-based operations typically have the key owner paying for the certificate .... while the major benefit accrues to the relying-party ... the key/certificate owner. In the case of SET ... there was the consumer payng for their certificate .... and the merchant not only receiving a better than MOTO-discount (making interchange transactions with the "SET" flag turned on ... somewhat suspecious) ... but also the possibility that the transaction would be treated as "authenticated" and potentially shifting the burden of proof in a dispute from the merchant to the consumer. There was the possibility that not only would the consumer be footing the bill (buying their own certificate) for the sole benefit of reducing what the merchant paid on the transaction .... but there was also speculation that it might also be used to make it more difficult for the consumer (there was sporadic mention of shifting the burden of proof from the merchant to the consumer in a dispute).

At least in the SSL domain name certificate, the merchant pays because of some belief that it will help attracted (internet) consumers/business.

In the SET/PKI scenario ... it was nearly impossible to figure out a value proposition for the consumer .... where the consumer is footing the (certificate) bill ... that turns out to be totally for the benefit of the merchant. It wasn't so much that cryptography took a wrong branch ... but many of the PKI business models don't conform to any sane business operation .... with the entity (key-owner) footing the bill not getting any benefit ... and all the benefit going to the relying-party.

The other generalized PKI issue (again not just SET) ... is "any" contract tends to be between the CA?PKI and the consumer .... aka the entity in a contract that purchases something. Frequently is no contractual relationship between the relying-parties .... who effectively the sole reason that the certificates exist ... and the CA/PKI. As mentioned elsewhere, the GSA PKI has attempted to somewhat address this by having all relying-parties sign contracts with the GSA .... and all the CA/PKI certificate issuing entities have a contract with the GSA where they are effectively issuing certificates on behalf of the GSA. Those set of contracts then preovide the legal foundation for some generic reason for relying-parties to do anything with certificates (since the relying-parties and the CA/PKI agency, aka GSA ... have contractual relationship and therefor a legal reason to deal with certificates). The slightly different SET scenario ... the associations just told the merchants that they would be charged less per transaction ... aka instead of MOTO (mail order, telephone order) discount, they could get something closer to card present discount.

Is cryptography where security took the wrong branch?

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 10 Sep 2003 08:14:14 -0600
To: bmanning@xxxxxxxx
Subject: Re: Is cryptography where security took the wrong branch?
Cc: lynn@xxxxxxxx (Anne & Lynn Wheeler), cryptography@xxxxxxxx
At 03:39 AM 9/10/2003 -0700, bmanning@xxxxxxxx wrote:
There are some other problems w/ using the DNS. No revolkation process. DNS caching third-party trust (DNS admins != delegation holder)

Since DNS is a online positive list .... you change the database ... and voila it is updated.

This is the scenario for credit cards going from pre-70s technology with plastic cards and the monthly revokation booklet mailed out to all merchants. The credit card industry transitioned to online infrastructure where it transactions are denied by updating the online database. It eliminates the revokation process, since there aren't an unknown number of copies of stale, static credentials/certificates floating around the world potentially being presented to an unknown variety of relying parties.

DNS caching is the closest equivalent of the certificate paradigm of stale, static copies floating around the world. The two slight differences are that cached stale, static entries tend to have very short lifetimes ... they come into creation by activities by the relying-party (not the entity being authenticated) and tend to have very short lifetimes .... of a few hours to at most a day. However, relying-parties have the choice of going directly to the root and obtaining the current copy .... a function somewhat filled in the PKI world by OCSP .... although OCSP is just a check about whether the current, stale, static copy in a relying-party's possession is current ... not what the current entry is..

From information theory standpoint, stale, static certificates are logically a form of long-lived, distributed, replicated, r/o, cache entries. Cache entry semantics have been studied in some detail in areas like distributed file systems and multiprocessor consistent shared memory caches, etc. With short-lived r/o, distributed cache entires (like DNS) ... there is a trade-off involving 1) entry life-time, 2) frequency of change, 3) impact of dealing with stale entry. We ran into a problem with doing consistent database updates over NFS (network filesystem) because while NFS advertises itself as idempotent, most client implementations have this 8k cache that can be stale.

Given high value &/or low trust ... relying parties still have option of directly contacting root authority. And as outline, the root authority is also the root authority for the CA/PKIs. If you attack the root trust authority with false information .... then all subsequent trust operations flowing from that false information is suspect. Domain name system still has some exploits against the root database resulting in false information .... but since that is the root for both DNS as well as CA/PKIs generating SSL domain name certificates .... it is a common failure point for both infrastructures. It needs to be fixed, in order to improve trust on either the DNS side or the CA/PKI side (doesn't matter how thick you make the vault door .... if somebody forgot to complete the back wall on the vault).

random, unrelated refs to past life working on processor cache design, distributed filesystems, and distributed databases
https://www.garlic.com/~lynn/subtopic.html#smp
https://www.garlic.com/~lynn/subtopic.html#hacmp

Is cryptography where security took the wrong branch?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 10 Sep 2003 12:56:05 -0600
To: bmanning@xxxxxxxx
Subject: Re: Is cryptography where security took the wrong branch?
Cc: cryptography@xxxxxxxx
At 09:57 AM 9/10/2003 -0700, bmanning@xxxxxxxx wrote:
ok... does anyone else want to "touch" a secured DNS system that has some parts fo the tree fully signed? Its a way to get some emperical understanding of how interesting/hard it is to hammer the DNS into a PKI-like thing.

www.rs.net has some information.


a normal cache-based system attempts to make everything appear as if it is online and dynamic .... with the characteristics of information caching as close as possibly transparent to the relying-parties.

one might claim that PKIs have tried to turn long-lived certificate-based "cache-entries" into a cult (aka from a information theory standpoint, certificates are a form of free-standing, somewhat self-describing, stale, static, long-lived cache entries) .... in part to create an independent revenue flow based on these cult objects. standard cache infrastructures usually attempt to go out of their way to try and make caching operation transparent to relying-parties (and can dynamically change/eliminate caching details to meet specific business requirement).

domain name infrastructure needs to support 1) trusted information distribution and may implement 2) cached entries. DNS has never been restricted to just trusted information distribution of IP-addresses.

CA/PKI SSL domain name certificates were deployed, in part because of integrity concerns about the domain name infrastructure. However, the "trust root" for CA/PKI SSL domain name certificates is still the domain name infrastructure (as to the authoritative owner of a domain name).

Turning DNS into a PKI-like thing happens only in the sense that CA/PKIs have only been a trusted distribution of public keys ... while DNS has always been a (somewhat) trusted distribution of any information (that happens to be registered with them). Adding public keys to DNS distribution is only turning it into a PKI-like thing from the standpoint that DNS hasn't in the past ben used as a trusted distribution for public key specific information (and the issue about the level of trust you can actually have in DNS).

My assertion is 1) DNS integrity issues have to be addressed as part of generalized DNS trust issues .... regardless of any use for trusted distribution of information that may include public keys. 2) because domain name infrastructure is the root authority for CA/PKI SSL domain name certificates, there is a suggestion that public keys be registered as part of domain name registration (to fix trust issues in domain infrastructure on behalf of the CA/PKI industry). Being able to trust DNS ... and having registered public keys .... means that existing DNS information distribution operation can turn into trusted distribution of public keys (aka existing DNS infrastructure supports distribution of any information that happens to be registered).

some past threads about transition steps for DNS trust .... which could include having cache entries that instead of being naked public keys could be digitally signed cache entries (sharing some characteristics in common to stale, static, long-lived, free-standing digitally signed certificate objects):
https://www.garlic.com/~lynn/aadsm12.htm#58 Time to ID Identity-Theft Solutions
https://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#36 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm14.htm#17 Payments as an answer to spam (addenda)
https://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
https://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
https://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
https://www.garlic.com/~lynn/aepay10.htm#84 Invisible Ink, E-signatures slow to broadly catch on (addenda)

Resolving an identifier into a meaning

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/11/2003 10:55 AM
To: Todd Boyle <tboyle@xxxxxxxx>
cc: david.berlind@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Resolving an identifier into a meaning.
fyi

some recent discussion of domain name infrastructure in cryptography mailing list
https://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#3 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#5 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#7 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#8 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#9 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#10 Is cryptography where security took the wrong branch?

and slightly related in sci.crypt newsgroup (some reference to IETF process and somewhat use DNS references as example):
https://www.garlic.com/~lynn/2003m.html#9 OSI not quite dead yet

and site with some more perspective on DNS
http://www.rs.net/

Going into in more detail in the above postings, one of the issues is the proposal to register public key at the same time as a domain name is registered (suggestion somewhat by CA/PKI industry). The current scenario for SSL domain name certificates .... is that there is some information stored in the domain name infrastructure database about the domain name owner and that the domain name infrastructure and the CA/PKI industry have been totally different business operations. In effect, a random person presents a request to a CA/PKI operation for a SSL domain name certificate. The CA/PKI operation then has to check with the domain name infrastructure as to the true owner of the domain name, map that information to some sort of real-world identification and then see if they can map the certificate requester's information to the same real world identification.

Registering a public key with the domain name registration, then reduces the problem for the CA/PKI industry to require digital signature on SSL domain name certificate requests ... and then the problem reduces to one of authentication ... which is much simpler than current problem of attempting to match real world identifications. The process for the CA/PKI industry becomes enormously simpler if they just have to pull the public key out of the domain name registration database for request authentication .... rather than having to go through the significantly more difficult process of matching up real world identifications.

The problem of real world identification in the domain name infrastructure then is left to the litigation going on about domain name squatters ... while requesting a SSL domain name certificate then is just an authentication issue ... not an identification issue.

tboyle@xxxxxxxx on 9/11/2003 9:58 am wrote:
Regarding David Berlind's "DNS inventor says cure to net identity problems is right under our nose",
https://web.archive.org/web/20030814211934/http://www.business-standard.com/ice/story.asp?Menu=119&story=20692

The DNS system is but one case of a HUGE class of problems, that includes all directories, as well as product lists, etc. Resolving an identifier into a meaning. Mockapetris should google around subjects like EDI code lists. or recall the X.500 wars, and Microsoft's campaign of over 10 years

to replace DNS with various directory schemes. Observe the requirements documents that gave birth to UDDI or ebXML RegRep. And observe how far THOSE have gotten. :-(

We all want convenience, robustness. But directory information is far too valuable to trust a single address resolver or to publish in a single monolithic form, accessible to all.

Clay Shirky writes about IM protocols, phone, fax, email, urls etc: "people have noticed how valuable it is to own a namespace..."
http://www.shirky.com/writings/dns.html

We're already too dependent on the IP numbering scheme and DNS. DNS is a POS. It is a single global namespace, yuck, what if there are 2 people named "Smith"? Go away Mockapetris, and all engineers of top-down hierarchic control. DNS is great but is not the only game in town.

We need a healthy diversity and competition in addressing schemes and resolvers. We need more work on the applications layer of the stack, to give users complete, sovereign control over their end-to-end conversations. And we need work aligning the information vertically within

the stack, so that the identity of the ULTIMATE owner of the conversation is not repeated and reified and abstracted and translated, fifty different times up and down the stack,

Todd Boyle http://www.ledgerism.net/P2Paxes.htm
contributor, ebXML Core Components Technical Specification


Resolving an identifier into a meaning

From: Lynn Wheeler
Date: 09/11/2003 01:43 PM
To: Todd Boyle <tboyle@xxxxxxxx>
cc: david.berlind@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Resolving an identifier into a meaning.
and to clear up a little confusion in the references in the previous

the OSI reference:
https://www.garlic.com/~lynn/2003m.html#9 OSI not quite dead yet

was in a thread about OSI/ISO vis-a-vis IETF ... using DNS activity as example of IETF workings.

The thread started by claiming that two major differences between ISO and IETF vis-a-vis OSI ... were

1) ISO disn't require actual implementation for something to become a standard (you can get standards that are not actually implementable) while IETF does

2) ISO attempted to cast OSI in concrete and make a cult of it for the true bleievers by instructing ISO-chartered standards bodies that they couldn't standardize networking protocols that violated the OSI model

https://www.garlic.com/~lynn/2003l.html#47 OSI not quite dead yet

Basically OSI model reflected 1960s era technology. To some extent the ARPANET during the 70s reflected the OSI model. By the early '80s (when OSI was finally passed, at least) two significant things had happened:

1) arpanet on 1/1/83 converted to internet(working) protocol ... something that doesn't exist in the OSI model

2) LANs appeared that subsume levels 1, 2, and part of 3 (in the OSI model) with a MAC interface that sits in the middle of layer 3.

Trying to get HSP (high-speed protocol) considered as standard in the late '80s in x3s3.3 (iso chartered us body responsible for networking protocols in OSI level 3&4) .... it had to be turned down. HSP would go directly from level 4 interface directly to LAN/MAC interface. Since LAN/MAC violated OSI ... and since ISO proscribed work on standards that violated OSI model .... it was not possible to standardize any network protocol that supported LAN/MAC interface.

Resolving an identifier into a meaning

From: Lynn Wheeler
Date: 09/11/2003 05:38 PM
To: Ed Gerck <egerck@xxxxxxxx>
cc: david.berlind@xxxxxxxx, internet-payments@xxxxxxxx,
    Todd Boyle <tboyle@xxxxxxxx>
Subject: Re: Resolving an identifier into a meaning.
egerck@xxxxxxxx on 9/11/2003 5:05 pm wrote:
You can further look at IP addresses as being hierarchical, but only for the purpose of routing on groups of addresses by virtue of their being assigned to be reachable through some specific address that looks like it is higher up in the "address tree".

minor note, ip addresses with respect to routing didn't become really hierarchical until sometime in '95 (???). we had been doing high availabilitity infrastructures with no single point of failure .... with multiple attachments to various places in the internet. It was still possible to advertise ability to get at the same ip-address via multiple paths. Sometime in '95 ... the infrastructure was getting to the point that full arbritrary routing tables were too big for most hardware boxes and there was an infrastructure decision to migrate to purely hierarchical routing.

At this point no single point of failure implementations were pretty much left with DNS multiple-A records .... aka DNS having multiple arbritrary ip-addresses (a-records) for a hostname. As an aside .... "rotating a-records" came into popularity about that same time as a partial solution for load-balancing (aka almost all client implementations always try a-records in the same order ... starting with the first).

while we had sign-off on the backend implementation part for what was becoming to be called e-commerce .... i.e. between the merchant servers and the payment gateway ... and so could require a number of things .... we had much less influence on the front-end/browser part of the infrastructure. Typical browser group response was "multiple A-record support was way too advanced" .... even after we showed them multiple A-record support from telnet client code in eight year old BSD 4.3 release. random refs:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

convoluted thread between loosely-coupled, supercomputers, high-availability, and electronic commerce
https://www.garlic.com/~lynn/2001i.html#52

lots of threads on the HA/CMP product we turned out
https://www.garlic.com/~lynn/subtopic.html#hacmp

Resolving an identifier into a meaning

Refed: **, - **, - **
From: Lynn Wheeler
Date: 09/12/2003 07:48 AM
To: internet-payments@xxxxxxxx
Subject: Re: Resolving an identifier into a meaning.
slight drift a new DNS RFC from Weds..
RFC 3597

Title Handling of Unknown DNS Resource Record (RR) Types
Author(s) A. Gustafsson
Status Standards Track
Date September 2003
Mailbox gson@xxxxxxxx
Pages 8
Characters 17559
Updates/Obsoletes/SeeAlso None

I-D Tag draft-ietf-dnsext-unknown-rrs-06.txt

URL ftp//ftp.rfc-editor.org/in-notes/rfc3597.txt

Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently.

This document is a product of the DNS Extensions Working Group of the IETF.


..... for a more complete list
https://www.garlic.com/~lynn/rfcietff.htm
select Term (term->RFC#) under RFCs listed by and then seelct "DNS" in the Acronym fastpath

Resolving an identifier into a meaning

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 09/12/2003 09:03 AM
To: Ed Gerck <egerck@xxxxxxxx>
cc: david.berlind@xxxxxxxx, Ed Gerck <egerck@xxxxxxxx>,
    internet-payments@xxxxxxxx, Todd Boyle <tboyle@xxxxxxxx>
Subject: Re: Resolving an identifier into a meaning.
egerck@xxxxxxxx on 9/11/2003 5:05 pm wrote:
You need a better ref ;-)

and yet another sowa reference:
http://www.jfsowa.com/ontology/ontoshar.htm

about the time I was doing some of the system/r (original relational) support infrastructure and tech. transfer to endicott for sql/ds
https://www.garlic.com/~lynn/submain.html#systemr

i was also helping with some of the support infrastructure for a semantic network database done as part of a VLSI chip tools effort (at VLSI lab several miles away). Some of it was influenced by Sowa who worked for the company at the time.

in another lifetime ... did some work on NLM's UMLS
https://www.garlic.com/~lynn/94.html#26 Misc. more on bidirectional links
http://www.nlm.nih.gov/research/umls/
http://www.nlm.nih.gov/pubs/factsheets/umlssemn.html

Since then we re-created (privately) some of it from scratch and we use it for the RFC index and the merged glossaries:
https://www.garlic.com/~lynn/
https://www.garlic.com/~lynn/rfcietff.htm
https://www.garlic.com/~lynn/index.html#glossary

total random trivia ... Mockapetris did some work for CSC at about the same time that "G", "M", & "L" were creating "GML" (aka their initials; which has since begot SGML, HTML, XML, FSML, SAML, et. al. ("G", "M", & "L" were all at CSC, 4th floor, 545 tech sq).
https://www.garlic.com/~lynn/subtopic.html#545tech
http://www.oasis-open.org/cover/sgmlhist0.html
https://web.archive.org/web/20230804173255/http://www.sgmlsource.com/history/
http://www.sgmlsource.com/history/G320-2094/G320-2094.htm

Some of the "ML" history thread was that CERN was a large VM/CMS shop (virtual machines and CMS ... originally cambridge monitor system and now conversational monitor system ... also originating from 4th floor, 545 tech. sq).

End of the line for Ireland's dotcom star

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 23 Sep 2003 13:45:42 -0600
To: "R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: End of the line for Ireland's dotcom star
Cc: cryptography@xxxxxxxx
At 01:06 PM 9/23/2003 -0400, R. A. Hettinga wrote:

http://www.guardian.co.uk/print/0,3858,4759214-103676,00.html


so ignore for the moment the little indiscretion
https://www.garlic.com/~lynn/2003l.html#44 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#50 Proposal for a new PKI model (At least I hope it's new)

and the part of turning a simple authentication problem into a significantly harder and error prone (along with exploits and vulnerabilities ... not to say expensive) problem:
https://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#7 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#11 Resolving an identifier into a meaning

there has been some past discussions of what happens to long term CA private key management over an extended period of time, possibly involving several corporate identities. Checking latest release browsers ... I find two CA certificates for GTE cybertrust ... one issued in 1996 and good for 10 years and another issued in 1998 and good for 20 years.

so lets say as part of some audit ... is it still possible to show that there has been long term, continuous, non-stop, highest security custodial care of the GTE cybertrust CA private keys. If there hasn't ... would anybody even know? ... and is there any institutional memory as to who might be responsible for issuing a revokation for the keys? or responsible for notifying anybody that the certificates no longer need be included in future browsers?

New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 29 Sep 2003 08:45:38 -0600
To: Guus Sliepen <guus@xxxxxxxx>
Cc: Cryptography list <cryptography@xxxxxxxx>
Subject: Re: New authentication protocol, was Re: Tinc's response to "Linux's answer to MS-PPTP"
On Mon, 2003-09-29 at 06:07, Guus Sliepen wrote:
TLS makes a distinction between a client and a server. If possible I wish to avoid making that distinction. If possible, I would also like to continue to be able to use an RSA public/private keypair. This made me sketch the following _authentication_ protocol:

... snip ...
Some questions: - Some people keep saying that "you shouldn't send the same kinds of messages". TLS sends different kinds of messages depending on its role (client or server). Is there a reason behind this? - Would it be nice to move all the cryptographic parameters exchanged in step 1 into the encrypted message in step 2? That way an attacker cannot see which encryption and digest algorithms will be used, which might make an attack less feasible. - Did I miss something?
  1. TLS both authenticates the server and establishes an encrypted session in the server part of the transaction.
  2. The original SSL somewhat assumed that the business requirements are different for server authentication (and encrypted session) vis-a-vis client authentication. The original SSL requirement a) was to give some level of confidence to the client that "the server that the client thot it was talking to" was actually "the server it was talking to" and b) provide an encrypted session. There wasn't actually a threat model requiring proving who you are ... just a threat model that the server prove that it was who the client supposedly thot it was.
  3. SSL was being deployed with a requirement for encrypted session in an environment where client authentication:
    1. might not be required
    2. was not required as part of the transport protocol
    3. was used to webize/tunnel an existing legacy application where the client might use userid/password or other authentication previously established
    4. wouldn't be public key based because the clients were not expected to have public/private key pairs and certificates

Some web'ized legacy applications were adopted from a private network environment ... where the client as part of making the connection "knew" that it was talking to the correct server. The minimum required to move that to the wide-open web ... was to provide server authentication and encrypted session ... and then tunnel the legacy app thru the encrypted session. The business requirement and threat model wasn't to invent a brand new environment from scratch ... but to adapt existing business operations to the wide-open web.

"Mutual" authentication was somewhat an add-on of client authentication to the base infrastructure. In fact, I think that we were the first to specify and required the first implementation as part of the back-end of this thing that has come to be called electronic commerce.

random electronic commerce refs:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

The trivial e-commerce is that the merchant server didn't really care who the client was ... just that the client bought something and the merchant was going to get paid. The merchant needed to provide some assurance that the credit card transaction being passed thru to the financial infrastructure was protected. The merchant relied on the financial infrastructure authenticating the credit card transaction ... and, in fact, any mutual authentication that might be done as part of the SSL transaction had no impact on the credit card transaction.

To some extent, both VPN and SSL come into existence about the same time to satisfy specific business requirement(s) (and in part because it was taking so long to see any progress with ipsec).

how simple is SSL? (Re: Monoculture)

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Adam Back <adam@xxxxxxxx>
Subject: Re: how simple is SSL? (Re: Monoculture)
Cc: Eric Rescorla <ekr@xxxxxxxx>, Don Davis <don@xxxxxxxx>,
"cryptography@xxxxxxxx" <cryptography@xxxxxxxx>,
Adam Back <adam@xxxxxxxx>
Date: Wed, 01 Oct 2003 16:18:10 -0600
At 02:21 PM 10/1/2003 -0700, Adam Back wrote:
Maybe but X.509 certificates, ASN.1 and X.500 naming, ASN.1 string types ambiguities inherited from PKIX specs are hardly what one could reasonably calls simple. There was no reason SSL couldn't have used for example SSH key formats or something that is simple. If one reads the SSL rfcs it's relatively clear what the formats are the state stuff is a little funky, but ok, and then there's a big call out to a for-pay ITU standard which references half a dozen other for-pay ITU standards. Hardly compatible with IETF doctrines on open standards you would think (though this is a side-track).

some related recent thread from comp.ssecurity.ssh n.g. (somewhat my standard harping about confusing the technology of digital signatures and the business issues of PKI and certificates):
https://www.garlic.com/~lynn/2003m.html#55 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003m.html#49 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003m.html#52 public key vs passwd authentication?

Simple SSL/TLS - Some Questions

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 07 Oct 2003 12:53:59 -0600
To: Jill Ramonsky <Jill.Ramonsky@xxxxxxxx>
Cc: cryptography@xxxxxxxx, ekr@xxxxxxxx
Subject: Re: Simple SSL/TLS - Some Questions
At 05:55 PM 10/3/2003 +0100, Jill Ramonsky wrote:
Having been greatly encouraged by people on this list to go ahead with a new SSL implementation, it looks like I am going to go for it, but I'd kinda like to not make any enemies in the process so I'll try to keep this list up to date with progress and decisions and stuff ... and I will ask a lot of questions.

really KISS/simple SSL/TLS .... given the business requirements for existing use (as opposed to existing technical specifications for existing implementations) is to register server's public key and crypto preferences in DNS .... when client calls DNS to get ip-address ... they can also request public key & crytpo preferences be returned in the same transmission. for transition purposes, the public key, crypto preferences, etc .... can exist in a authoritative signed message by some generally recognized trusted party .... a mini-certificate (if you will).

the client generates a random session key according to the crypto preferences, encrypts a credit card number and misc. ancillary transaction info with the session key, encrypts the session key with the public key (if you really want to simplify to the business requirements, directly encrypt with the public key and eliminate the session key step) .... and use a XTP-like (or some of the emerging real-time protocol) .... aka existing SSL is carried on top of TCP .... TCP requires a minimum of 7 packet exchange .... and SSL on top of that then requires all the negotiation chatter.

Having the public key (& possibly crypto preferences .... unless you want to directly encrypt with the public key) piggy-back with the DNS request .... then the actual transaction can be done in three-packet exchange (i.e. XTP defines a minimum three-packet exchange for reliable transaction).

This is about as simplified SSL/TLS as you can get based on business requirements for the major existing applications using SSL/TLS

some past related comments
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

Simple SSL/TLS - Some Questions

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 07 Oct 2003 13:15:18 -0600
To: EKR <ekr@xxxxxxxx>
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
Jill Ramonsky <Jill.Ramonsky@xxxxxxxx>, cryptography@xxxxxxxx
Subject: Re: Simple SSL/TLS - Some Questions
At 12:09 PM 10/7/2003 -0700, Eric Rescorla wrote:
This doesn't provide equivalent services to TLS--no anti-replay service for the server.

KISS ... for the primary business requirement .... the application already has anti-replay .... TLS ant-replay is then redundant and superfluous.

yes, it isn't existing TLS .... it is KISS TLS based on primary business requirement ... as mentioned in original, not on existing specification for existing implementation
https://www.garlic.com/~lynn/aadsm15.htm#19

when doing the original deployment stuff
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

there was the idea in would be used for the whole online experience. The subsequent comments was that it got cut back to the current primary use .... because it imposed a five-fold overhead increase (or reduced a server service capacity by 80 percent).

Making it significantly more simple and lightweight might encourage it to be used more extensively.

Simple SSL/TLS - Some Questions

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 07 Oct 2003 21:53:32 -0600
Subject: Re: Simple SSL/TLS - Some Questions
To: iang@xxxxxxxx
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
    EKR <ekr@xxxxxxxx>,
Jill Ramonsky <Jill.Ramonsky@xxxxxxxx>,
cryptography@xxxxxxxx
At 08:38 PM 10/7/2003 -0400, Ian Grigg wrote:
You are not being fair, Lynn, you are hijacking the name of TLS, in order to promote a protocol to protect credit cards.

What you described was practically nothing to do with TLS/SSL...

Such a protocol would be quite useful no doubt, but it has little to do with TLS' design goal of being a full service channel security product.


what i said was that it was specifying a simplified SSL/TLS based on the business requirements for the primary use of SSL/TLS .... as opposed to a simplified SSL/TLS based on the existing technical specifications and existing implementations.

I don't say it was technical TLS .... I claimed it met the business requirements of the primary use of SSL/TLS.

I didn't preclude that there could be simplified SSL/TLS based on existing technical specifications as opposed to implementation based on business requirements for the primary use.

I thot I was very fair to distinguish between the business requirements use of SSL/TLS as opposed to technical specifications for SSL/TLS.

There are lots of really great implementations in this world .... many of which have absolutely no relationship at all with a good business reason to exist.

The real observation was that in the early deployments of SSL .... it was thot it would be used for something entirely different ... and therefor had a bunch of stuff that would meet those business requirements. However, we come to find out that it was actually being used for something quite a bit different with different business requirements.

So a possible conjecture is that if there had been better foreknowledge as to how SSL was going to be actually be used .... one might conjecture that it would have looked more like something I suggest (since that is a better match to the business requirements) ... as opposed to matching some business requirements for which it turned out not to be used.q

As to usefulness .... I wasn't really trying to claim it would be useful .... just that it would meet the business requirements of its primary use.

I've repeatedly claimed that the credit card number in flight has never been the major threat/vulnerability .... the major threat (even before the internet) has always been the harvesting of the merchant files with hundreds, thousands, tens of thousands, even millions of numbers .... all neatly arranged.

The issue that we were asked to do in the X9A10 working group was to preserve the integrity of the financial infrastructure for all electronic retail payments. A major problem is that in the existing infrastructure, the account number is effectively a shared-secret and therefor has to be hidden. Given that there are dozens of business processes that require it to be in the clear at potentially millions of locations .... there is no practical way of addressing integrity of such a shared-secret (you could burry the earth to the depth of a couple miles with cryptography .... and it still wouldn't alleviate the threat).

It turns out that once the account number is no longer a shared-secret .... then it is no longer necessary to hide it in order to preserve the integrity of the financial infrastructure. At that point, a primary existing use of SSL/TLS goes away completely.

I wasn't really to hijack the protocol .... however, if you wanted to simplify something based on the business requirements of its use ... then one might consider simplifying based on the business requirements of its use (even if it became somewhat different). My strong preference (by several orders of magnitude) is to not do anything to contribute to delays of eliminating account numbers as shared-secrets (that would include not contributing to an extreme KISS TLS other than a hypothetical mental exercise related to business justification as a reason for doing something)..

I would prefer the primary justification for SSL/TLS to totally disappear. There then might remain some other uses that could benefit from SSL/TLS .... and they might not have a need for simplification at all.

Frequently when simplification is done to something .... you throw away stuff that isn't needed (at least for the targeted business purpose). The issue in extreme KISS TLS .... at what point has it become so simple that it can no longer be TLS ... aka what is the minimal simple set of things needed for something to still be TLS?

simple result of the x9a10 working group to preserve the integrity of the financial infrastructure for all electronic retail payments .... and eliminate account numbers as shared-secrets
https://www.garlic.com/~lynn/x959.html#x959

Trusting the Tools - was Re: Open Source

Date: Sun, 12 Oct 2003 08:25:21 -0600
To: tls@xxxxxxxx
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Trusting the Tools - was Re: Open Source ...
Cc: Bill Frantz <frantz@xxxxxxxx>, cryptography@xxxxxxxx
At 04:27 AM 10/12/2003 -0400, Thor Lancelot Simon wrote:
Not too good. If I knew what the target processor were, I think I could arrange to do some damage to most general-purpose operating systems; they all have to do some of the same fundamental things.

This is a bit more sophisticated than what Thompson's compiler did, but it's the same basic idea. There are some basic operations (in particular on the MMU) that you can recognize regardless of their specific form and subvert in a progammatic manner such that it's highly likely that you can exploit the resulting weakness at a later date, I think.


remember

  1. that it is more straight-forward to check assembler generated code since there is nearly a one-to-one correspondance between the assembler statement and the generated machine code
  2. default assembly program generated listings shows assembler statement and the corresponding generate machine instruction
  3. the assembler was widely used thru-out the world
  4. the source of the assembler was available
  5. there were things like the SLAC assembler enhancements (just down/up the road)
  6. people available (like people that did SLAC mods) that had dealt with the source of the assembler
  7. some organizations that extensively used such systems that did study some of these issues in more detail
  8. people dealing with development and debugging assembler-based systems normally are operating between the assembler listings (showing one-to-one between assembler statement and generated machine instruction) and what appears in memory.
  9. assembler program listing also summarizes code size .... and is also frequently and commonly used in manual mapping to memory image.


It wouldn't have been impossible ... but quite unlikely. It is somewhat easier in C-based programs since there are additional levels of indirection and obfuscations between the statements in a C program and the generated machine code.

NCipher Takes Hardware Security To Network Level

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: NCipher Takes Hardware Security To Network Level
To: pgut001@xxxxxxxx (Peter Gutmann)
Cc: astiglic@xxxxxxxx, cryptography@xxxxxxxx, pgut001@xxxxxxxx
Date: Mon, 13 Oct 2003 15:13:42 -0600
At 10:22 PM 10/13/2003 +1300, Peter Gutmann wrote:
So why is this stuff still present in the very latest certification requirements? Because we're measuring what we know how to measure, whether it makes sense to evaluate security in that way or not. This is probably why penetrate-and-patch is still the most widely-used approach to securing systems. Maybe the solution to the problem is to figure out how to make penetrate-and-patch more rigorous and effective...

I would contend that the penetrate-and-patch model is because the original base was not designed for 7x24, fully interconnected environment. some slightly related comments on the subject:
https://www.garlic.com/~lynn/2003n.html#14 Poor People's OS

The air force found none of the problems in the studied infrastructure:
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#43 another 30 year thing
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2003i.html#59 grey-haired assembler programmers (Ritchie's C)
https://www.garlic.com/~lynn/2003j.html#4 A Dark Day

the contention is that the system was designed to handle the circumstances. The currently common distributed software was not originally designed to handle this kind of situation .... and repeatedly it has been demonstrated for assurance to work well .... it has to be designed in from the start .... not added on afterward.

At various times, we had polite competition since the work referenced in the air force study was done on the 5th floor of 545 tech. sq ... and I was on the 4th floor ... also working on what was considered a secure (but totally different) system.
https://www.garlic.com/~lynn/subtopic.html#545tech

There were issues about unfair comparison since at the time of the following .... the totally number of systems ever existing for the 5th floor system was something over one hundred. The total number of just internal corporate machines running the 4th floor system was in the thousands and the number of customer machines were low tens of thousands. So we just had light hearted competition with regard to just code I wrote .... and the number of (internal) machines that I directly provided systems for (something over a hundred ... comparable to the total number of 5th floor systems).

The following reference was the system that the air force data center in the pentagon was running was getting old ... and they were looking at newer hardware, in this case initially twenty newer machines, each with about the same MIP rate of the aging machine running the 5th floor system. As referenced, this then turned into 210 such machines:
https://www.garlic.com/~lynn/2001m.html#15 departmental servers

Homeland Security chief mulls SEC cybersecurity filings

From: InfoSec News <isn@xxxxxxxx>
To: isn@xxxxxxxx
Subject: [ISN] Homeland Security chief mulls SEC cybersecurity filings
Date: Tue, 14 Oct 2003 07:21:23 -0500 (CDT)
Forwarded from: Anne & Lynn Wheeler <lynn@xxxxxxxx>


https://www.garlic.com/~lynn/aepay3.htm#riskm Thread Between Risk Management and Information Security
<NOTE: inclusion of the above reference was because the subject of cybersecurity in SEC fillings was discussed in some detail at the meeting; also:
https://www.garlic.com/~lynn/aepay3.htm#riskaads AADS & Risk Management, and Information Security Risk Management (ISRM)


http://www.computerworld.com/securitytopics/security/story/0,10801,85888,00.html
Homeland Security chief mulls SEC cybersecurity filings
Companies could be required to detail cybersecurity efforts

Story by Andy Sullivan
OCTOBER 09, 2003
REUTERS

Publicly traded companies could be required to disclose whether they are doing anything to secure information on their computer systems, U.S. Department of Homeland Security Secretary Tom Ridge said today.

Ridge said he had met with William Donaldson, chairman of the U.S. Securities and Exchange Commission, to discuss whether companies should be required to disclose cybersecurity efforts in their SEC filings.


[...]

WYTM?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: 10/17/2003 10:05 AM
To: "John S. Denker" <jsd@xxxxxxxx>
cc: David Honig <dahonig@xxxxxxxx>, cryptography@xxxxxxxx
Subject: Re: WYTM?
On Fri, 2003-10-17 at 00:58, John S. Denker wrote:
Tangentially-related point about credentials:

In a previous thread the point was made that anonymous or pseudonymous credentials can only say positive things. That is, I cannot discredit you by giving you a discredential. You'll just throw it away. If I somehow discredit your pseudonym, you'll just choose another and start over.

This problem can be alleviated to some extent if you can post a fiduciary bond. Then if you do something bad, I can demand compensation from the agency that issued your bond. If this happens a lot, they may revoke your bond. That is, you can be discredited by losing a credential.

This means I can do business with you without knowing your name or how to find you. I just need to trust the agency that issued your bond. The agency presumably needs to know a lot about you, but I don't.


One can claim this is what a credit card does for the consumer .... the name on the card is somewhat tangential to it being a credential; it is there so that the merchant can authenticate the credential by cross checking the name on the card with names on other credentials that you might be carrying. If you have enuf credentials with the same name ... then it eventually satisfies the merchant that it is your credential.

Some number of places are taking the name off the card .... as part of improving consumer privacy at point-of-sale. They can do this with debit .... where the PIN is a substitution for otherwise proving it is your credential. however, as previously posted there is a lot of skimming going an with the information for making a counterfeit card as well as skarfing up the corresponding PIN.

This is also being done with some kinds of chip cards .... where a PIN is involved .... but since the infrastructure "trusts" the cards .... the counterfeit cards are programmed to accept any PIN .... see the yes card at the bottom of the following URL.
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
access problems, trying wayback machine
https://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
The issue is that technique used to skim static data for making counterfeit magstripe cards also applies to skimming static data for making counterfeit yes cards.

The claim in X9.59 is that the signature from something like an asuretee card ... can both demonstrate two (or three) factor authentication as well as proving that the transaction hasn't been tampered with since it was signed.

In this case, while the card may still look like an (offline) credential from pre-1970s (with printed credential revokation lists mailled out every month to all merchants) .... it, in fact does an online transaction. The digital signature proving 2/3-factor authentication (and no transaction tampering during transit) is then accepted (or not) by the financial institution which reports back real-time result to the relying party (merchant).

This is a move from the ancient offline paradigm that has been going on for hundreds of years (with credentials as substitute for real-time interaction) to an online paradigm. While the form-factor may still appear the same as the rapidly becoming obsolete offline credential; it is actually operating as a long-distance 2/3-factor authentication mechanism between the consumer and their financial institution .... with the merchant/relying-party getting back a real-time response as to whether the institution stands behind the request.

The difference between the x9.59/asuretee implementation and the "yes card" implementation is that there is no static data to skim (and use for creating counterfeit cards/transactions).

misc. x9.59 refs:
https://www.garlic.com/~lynn/x959.html#x959

misc. aads chip strawman & asuretee refs:
https://www.garlic.com/~lynn/x959.html#aads

The integrity of the chipcard and the integrity of the digital signature substitutes for requiring the merchants to cross-check the name on the card with the names on an arbitrary number of other "credentials" until they are comfortable performing the transaction.

The current (non-PIN card) infrastructure is sort of half way between the old style "everything is a credential" and the new "everything is online" .... to a fully trusted online infrastructure. The magstripe does an online transaction and the institution will approve the transactions with some number of caveats regarding it not being a counterfeit/fraudulent transaction. For the non-PIN transactions, the merchant (can) uses the name on the card to cross check with as many other credential names until the merchant becomes comfortable.

This is similar to the scenario with the existing SSL domain name certificate issuing process (using names mapping to common/real-world identities in order to achieve authentication). The domain name system registers the owner's name. The CA SSL certificate issuer obtains a name of the certificate requester .... and then the CA attempts to map the two names into the same real world identities as a means of achieving authentication. The drastically simpler solution is the domain name system registers a public key at the same time as registering the domain name. Then the SSL certificate issuer, instead of having to map real world identities in order to achieve authentication .... can just use the registered public key to achieve authentication. The catch-22 is that if the SSL certificate issuer can use the registered public key for authentication (instead of the much harder problem of trying to map names into the same real word identities) ... then lots of other entities can also use the registered public key for authentication .... significantly decreasing the need for such a SSL certificate.

The integrity of the chipcard and the integrity of the digital signature substitutes for requiring the merchants to cross-check the name on the card with the names on an arbritrary number of other "credentials" until they are confortable performing the transaction.

recent threads discussing identification when all that is needed is authentication:
https://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#11 Resolving an identifier into a meaning

SSL, client certs, and MITM (was WYTM?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: tom.otvos@xxxxxxxx
Cc: cryptography@xxxxxxxx
Date: Wed, 22 Oct 2003 14:27:30 -0600
Subject: Re: SSL, client certs, and MITM (was WYTM?)
On Wed, 2003-10-22 at 13:46, Tom Otvos wrote:
I read the "WYTM" thread with great interest because it dovetailed nicely with some research I am currently involved in. But I would like to branch this topic onto something specific, to see what everyone here thinks.

As far as I can glean, the general consensus in WYTM is that MITM attacks are very low (read: inconsequential) probability. Is this *really* true? I came across this paper last year, at the SANS reading room:


https://web.archive.org/web/20030217202811/www.sans.org/rr/threats/man_in_the_middle.php

I found it both fascinating and disturbing, and I have since confirmed much of what it was describing. This leads me to think that an MITM attack is not merely of academic interest but one that can occur in practice. With sufficiently simplified tools this type of attack can readily be launched by "script kiddies" or someone only just slightly higher on the hacker evolutionary scale. Having said that then, I would like to suggest that one of the really big flaws in the way SSL is used for HTTP is that the server rarely, if ever, requires client certs. We all seem to agree that convincing server certs can be crafted with ease so that a significant portion of the Web population can be fooled into communicating with a MITM, especially when one takes into account Bruce Schneier's observations of legitimate uses of server certs (as quoted by Bryce O'Whielacronx). But as long as servers do *no* authentication on client certs (to the point of not even asking for them), then the essential handshaking built into SSL is wasted. I can think of numerous online examples where requiring client certs would be a good thing: online banking and stock trading are two examples that immediately leap to mind. So the question is, why are client certs not more prevalent? Is is simply an ease of use thing? Since the Internet threat model upon which SSL is based makes the assumption that the channel is *not* secure, why is MITM not taken more seriously? Why, if SSL is designed to solve a problem that can be solved, namely securing the channel (and people are content with just that), are not more people jumping up and down yelling that it is being used incorrectly? Am I missing something obvious here? I look forward to any comments you might have.


in general SSL domain name certs address
  1. is the server I think I'm talking to really the server that I'm talking to (is the URL I entered match the URL in the certificate)
  2. key exchange, for an encrypted session
So what purpose would client certificates address? Almost all of the use of SSL domain name certs is to hide a credit card number when a consumer is buying something. There is no requirement for the merchant to identify and/or authenticate the client .... the payment infrastructure authenticates the financial transaction and the server is concerned primarily with getting paid (which comes from the financial institution) not who the client is.

So, there are some infrastructures that have web servers that want to authenticate clients (for instance online banking). They currently establish the SSL session and then authenticate the user with userid/password against an online database.

The fact is .... one contention is that possibly 99.9999 percent of the client-based authentication that happens in the world today is done against some database.

There was an instance of a bank issuing client certificates for use in online banking. At one time they claimed to have the largest issued PKI client certificates (aka real PKI as opposed to manufactured certificates).

However, they discovered
  1. the certificates had to be reduced back to relying-party-only certificates with nothing but an account number (because of numerous privacy and liability concerns)
  2. the certificates quickly became stale
  3. they had to look up the account and went ahead and did a separate password authentication .... in part because the certificates were stale.
They somewhat concluded that the majority of client certificate authentication aren't being done because they want the certificates .... it is because the available COTS software implements it that way (if you want to use public key) ... but not because certificates are in anyway useful to them (in fact, it turns out that the certificates are redundant and superfluous ... and because of the staleness issue resulted in them also requiring passwords).

So a reasonable suggestion was to ship webservers .... with a radius stub for the client authentication interface. The client registers authentication material (in much the same way that nearly all of the ISP authentication infrastructures operate).

If the desire is to have something better than passwords or shared-secrets (aka trying to help the world address the huge propagation of number of shared-secrets per person that is occuring in the online world), then it would be possible to register a public key in the radius database ... and authenticate with a digital signature as opposed to a shared-secret.

A certificate is to address the trust propagation between two entities that have had no prior relationship (and possibly may never in the future have any sort of relationship) and there is not any other kind of recourse .... it is purely possible to have digital signature strong authentication when certificates aren't involved in anyway what-so-ever.

If you eliminate all the scenarios where the entities have no prior relationship and/or have no recourse to an online service then you are pretty much done to a zero set. The scenario with a random customer at a random merchant website ... never before visited ... the merchant is interested in getting paid .... the customer contacts their bank (prior business relationship), the customer bank contacts the merchant bank (prior business relationship), and the merchant bank contacts the merchant (prior business relationship) .... to tell the merchant that they will get paid (aka the real-time response from the financial infrastructure means a lot more to the merchant than anything that a random, unknown consumer might claim ... regardless of any possible redundant and superfluous certificate that might be involved).

SSL, client certs, and MITM (was WYTM?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: <tom.otvos@xxxxxxxx>
Cc: <cryptography@xxxxxxxx>
Date: Wed, 22 Oct 2003 15:58:33 -0600
Subject: RE: SSL, client certs, and MITM (was WYTM?)
At 05:08 PM 10/22/2003 -0400, Tom Otvos wrote:
The CC number is clearly not hidden if there is a MITM. I think the "I got my money so who cares where it came from" argument is not entirely a fair representation. Someone ends up paying for abuses, even if it is us in CC fees, otherwise why bother encrypting at all? But that is besides the point.

the statement was SSL domain name certificate is
  1. am i really talking to who I think I'm talking to
  2. encrypted channel
obviously #1 addresses MITM (am i really talking to who I think I'm talking to).

The issue for CC is that it really is a shared-secret and is extremely vulnerable ... as I've commented before
  1. CC needs to be in the clear in a dozen or so business processes
  2. much simpler to harvest a whole merchant file with possibly millions of CC numbers in about the same effort to evesdrop one off the net (even if there was no SSL) return on investment .... for approx. same amount of effort get one CC number or get millions
  3. all the instances in the press are in fact involved with harvesting large files of numbers ... not one or two at a time off the wire
  4. burying the earth in miles of crypto still wouldn't eliminate the current shared-secret CC problem
slightly related .... security proportional to risk:
https://www.garlic.com/~lynn/2001h.html#61

so the requirement given the X9 financial standards working group X9A10
http://www.x9.org/

was to preserve the integrity of the financial infrastructure for all electronic retail payment (regardless of kind, origin, method, etc). The result was X9.59 standard
https://www.garlic.com/~lynn/x959.html#x959

which effectively defines a digitally signed, authenticated transaction .... no certificate required ... and the CC number used in X9.59 authenticated transactions shouldn't be used in non-authenticated transactions. Since the transaction is now digitally signed transactions and the CC# can't be used in non-authenticated transactions .... you can listen in on X9.59 transactions and harvest all the CC# that you want to and it doesn't help with doing fraudulent transactions. In effect, X9.59 changes the business rules so that CC# no longer need to be treated as shared-secrets.

misc. past stuff about ssl domain name certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

misc. past stuff about relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

misc. past stuff about using certificate-less digital signatures in radius authentication
https://www.garlic.com/~lynn/subpubkey.html#radius

misc. past stuff about using certificate-less digital signatures in kerberos authentication
https://www.garlic.com/~lynn/subpubkey.html#kerberos

misc. fraud & exploits (including some number of cc related press announcements)
https://www.garlic.com/~lynn/subintegrity.html#fraud

some discussion of early SSL deployment for what is now referred to as electronic commerce
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

SSL, client certs, and MITM (was WYTM?)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: <tom.otvos@xxxxxxxx>
Cc: <iang@xxxxxxxx>, <cryptography@xxxxxxxx>
Date: Wed, 22 Oct 2003 18:36:35 -0600
Subject: RE: SSL, client certs, and MITM (was WYTM?)
At 05:42 PM 10/22/2003 -0400, Tom Otvos wrote:
Absolutely true. If the "only" effect of a MITM is loss of privacy, then that is certainly a lower-priority item to fix than some quick cash scheme. So the threat model needs to clearly define who the bad guys are, and what their motivations are. But then again, if I am the victim of a MITM attack, even if the bad guy did not financially gain directly from the attack (as in, getting my money or something for free), I would consider "loss of privacy" a significant thing. What if an attacker were paid by someone (indirect financial gain) to ruin me by buying a bunch of stock on margin? Maybe not the best example, but you get the idea. It is not an attack that affects millions of people, but to the person involved, it is pretty serious. Shouldn't the "server" in this case help mitigate this type of attack?

ok, the original SSL domain name certificate for what became electronic commerce was
  1. am I really talking to the server that I think I'm talking to
  2. encrypted session.
so the attack in #1 was plausably some impersonation ... either MITM or straight impersonation. The issue was that there was a perceived vulnerability in the domain name infrastructure that somebody could contaminate the domain name look up and get the ip-address for the client redirected to the impersonater.

The SSL domain name certificates carry the original domain name .... the client validates the domain name certificate with one of the public keys in the browser CA table ... and then validates that the server that it is communicating with can sign/encrypt something with the private key that corresponds to the public key carried in the certificate ... and then the client compares the domain name in the certificate with the URL that the browser used. In theory, if all of that works .... then it is highly unlikely that the client is talking to the wrong ip-address (since it should be the ip-address of the server that corresponds to the server).

So what are the subsequent problems:
  1. the original idea was that the whole shopping experience was protected by the SSL domain name certificate .... preventing MITM & impersonation attacks. However, it was found that SSL overhead was way to expensive and so the servers dropped back to just using it for encryption of purchase/payment. This means that the client ... does all their shopping ... with the real server or the imposter ... and then clicks on a button to check out that drops the client into SSL for the credit card number. The problem is that if it is an imposter ... the button likely carries a URL for which the imposter has a valid certificate for.
  2. the original concern was possible ip-address hijacking in the domain name infrastructure .... so the correct domain name maps to the wrong ip address .... and the client goes to an imposter (whether or not the imposter needs to do an actual MITM or not). The problem is that when somebody approaches a CA for a certificate .... the CA has to contact the domain name infrastructure as to the true owner of the domain name. It turns out that integrity issues in the domain name infrastructure not only can result in ip-address take-over .... but also domain name take-over. The imposter exploits integrity flaws in the domain name infrastructure and does a domain name take-over .... approaches a CA for a SSL domain name certificate ... and the CA issues it ... because the domain name infrastructure claims it is the true owner.
So somewhat from the CA industry ... there is a proposal that people register a public key in the domain name database when they obtain a domain name. After that ... all communication is digitally signed and validated with the database entry public key (notice this is certificate-less). This has the attribute of improving the integrity of the domain name infrastructure ... so the CA industry can trust the domain name infrastructure integrity so the rest of the world can trust the SSL comain name certificates?

This has the opportunity for simplifying the SSL domain name certificate requesting process. The entity requesting the SSL domain name certificate .... digitally signs the request (certificate-less of course). The CA validates the SSL domain name certificate request by retrieving the valid owner's public key from the domain name infrastructure database to authenticate the request. This is a lot more efficient and has less vulnerabilities than the current infrastructure.

The current infrastructure has some identification of the domain name owner recorded in the domain name infrastructure database. When an entity requests a SSL domain name certificate ... they provide additional identification to the CA. The CA now has to retrieve the information from the domain name infrastructure database and map it to some real world identification. They then have to take the requester's information and also map it to some real world identification. They then have to try and see if the two real word identifications match. The recording of the public key for certificate-less authentication ... not only improves the integrity of the domain name infrastructure (so that it can be better trusted by the CA industry) .... but it can also convert a very error prone identification process for certificates into a simple authentication process.

So now we have the catch-22 clinker for the CA industry (since they are somewhat sponsoring this whole idea)
  1. if the certificate-less public key process improves the integrity of the domain name infrastructure, then one can claim that the integrity concerns about the domain name infrastructure are lessoned and therefor the perceived requirement for SSL domain name certificates is lessoned
  2. if the CA industry can use the registered public key for certificate-less authentication regarding domain name related operations ... then presumably the rest of the world can also ... which would further eliminate justifications for SSL domain name certificates (i don't need to get the server's public key from a certificate .... I could get it from a dynamic, trusted, information distribution utility ... the domain name infrastructure).
as before ... misc SSL domain name certificate related posts:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

the following also have some references to domain name hijacking events (as opposed to ip-address hijacking):
https://www.garlic.com/~lynn/subintegrity.html#fraud

SSL, client certs, and MITM (was WYTM?)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: <tom.otvos@xxxxxxxx>
Cc: <iang@xxxxxxxx>, <cryptography@xxxxxxxx>
Date: Thu, 23 Oct 2003 09:43:04 -0600
Subject: RE: SSL, client certs, and MITM (was WYTM?)
Internet group starts anit-hacker initiative
http://www.computerweekly.com/articles/article.asp?liArticleID=125823&liArticleTypeID=1&liCategoryID=2&liChannelID=22&liFlavourID=1&sSearch=&nPage=1

one of the threats discussed in the above is the domain name ip-address take-over mentioned previously
https://www.garlic.com/~lynn/aadsm15.htm#28

which was one of the primary justifications supposedly for SSL deployment (am i really talking to the server that I think i'm talking to).

NSA Buys License for Certicom's Encryption Technology

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: cryptography@xxxxxxxx
Date: Sun, 26 Oct 2003 07:08:27 -0700
Subject: NSA Buys License for Certicom's Encryption Technology

http://www.eweek.com/article2/0,4149,1363251,00.asp
NSA Buys License for Certicom's Encryption Technology
By Dennis Fisher
October 24, 2003

In an extraordinary move, the National Security Agency has purchased a license for Certicom Corp.'s elliptic curve cryptography (ECC) system, and plans to make the technology a standard means of securing classified communications.

As part of the $25 million agreement, the NSA can grant sublicenses within a limited field of use. This most likely will include other government agencies, federal contractors and other parties that send sensitive data to the agency.


... snip ...

Electronic Safety and Soundness: A Four Pillar Approach; Public Policy Issues

Refed: **, - **, - **
From: Lynn Wheeler
Date: 10/30/2003 11:42 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Electronic Safety and Soundness: A Four Pillar Approach; Public Policy Issues
Having made minor contribution to

Electronic Safety and Soundness: A Four Pillar Approach; Public Policy Issues

a new paper appearing soon at:
http://www1.worldbank.org/finance/

in the e-security/e-finance section
http://wbln0018.worldbank.org/html/FinancialSectorWeb.nsf/9f941053fd4293dc852569510022c5a0/77768cb67681ae7c85256d09005807df?OpenDocument

from the Forward:
Over the last decade technological advances have been revolutionizing the conduct of commerce and financial transactions. Technology has allowed financial services to be provided to a wider variety of institutional and retail clients at far lower transaction costs, with important implications for access to financial services. The advent of the Internet and advances in cellular, wireless, and satellite technology have multiplied the possibilities for moving digital information. Many emerging markets are aggressively adopting advanced technologies in efforts to bridge the ''digital divide.''

However, the increasing use of these technologies, especially in emerging markets, is not without risk. These systems, which rely on computers and the Internet technology backbone, are vulnerable to rapid, illegal intrusions that can disrupt, disable or corrupt critical infrastructure such as power, telecommunications, government, education, hospitals, and financial services. Privacy, security, safety and soundness are all at stake as service providers race to use these technologies to integrate functions and services at a higher speed and reduced cost. In a series of papers starting over three years ago, staff in the Financial Sector Operations and Policy Department in the World Bank have investigated the links between technology advances and financial sector development and access to financial services, with a particular emphasis on electronic security (e­security) concerns.


past refs to world bank papers:
https://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
https://www.garlic.com/~lynn/aepay12.htm#25 Cyber Security In The Financial Services Sector
https://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates
https://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
https://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature

VS: On-line signature standards

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 10/31/2003 08:56 AM
To: pekka honkanen Welho <lhonkane@xxxxxxxx>
cc: 'Anders Rundgren' <anders.rundgren@xxxxxxxx>,
    'internet-payments' <internet-payments@xxxxxxxx>
Subject: Re: VS: On-line signature standards
as i've mentioned before certificates have very little to do directly with digital signatures .... they are a mechanism for trust propagation ... akin to the letters of credit from the days of sailing ship .... where the relying party had no direct and/or online knowledge of the signing party and no direct and/or online access to the certifying party.

however, the scenario for the financial relying-party-only certificates issue that were distributed during the 90s .... are analogous to requiring that when I go into my bank branch office to negotiate with the branch manager .... I first go into my bank branch office and talk the branch manager into giving me a letter of credit credential to introduce me to some stranger, relying party .... I then leave the bank branch, re-enter the same bank branch and go to the same branch manager and present the letter of credit credential (that they just created) as a prelude to the branch manager doing business with me.

There has been some past discussions with regard to certificates that carry a non-repudiation indication and something that has been severely depreciated. I believe originally, there was some desire to differentiate to unknown, relying-parties (aka strangers) the difference between the entity's use of keys for data hidning and keys for authentication. These are effectively totally different business processes relying on the same technology. However, one issue in the difference in the business processes is that data hiding (encryption) keys tend to require that the private key be escrowed (for business continuity reasons) and the business processes for authentication requires that the private key never be divulged. However, there seemed to have been some aggradizement of the business process authentication concept to non-repudiation.

One of the things seen (in at least the cal. state electronic signature law and the US federal electronic signature law) is that there is a somewhat explicit deliniation between demonstrating intention (as required by things like contract law and non-repudiation) and authentication. A digital signature can demonstrate authentication (and exists totally independently of whether certificates exist or not as part of providing trust propagation to relying party strangers). However, it is pretty clear than to demonstrate intention and/or agreement that there is a lot more required (to form basis of valid signature ... as per law) ... and also has resulted in depreciation of any reference to non-repudiation with regard to X.509 ... since there is nothing (little?) in X.509 that provides the basis for non-repudiation. The electronic signature law references a bunch of stuff required for a valid/binding legal signature and non-repudiation ... and it has little or nothing to do directly with "digital signatures" ... therefor the more general reference being made to "electronic signatures" (as well as nothing to do with the need for trust propagation as represented by certificates). It is possible for "digital signatures" to be used in conjunction with other things to be a valid "electronic signature" ... however there are a number of other authentication methods that can be used in conjunction with intention/non-repudiation operations that also satisfy the requirement for "electronic signature".

to some extent a digital signature is purely a demonstration of one or two factors from the three factor authentication model:
something you have
something you know
something you are

A valid digital signature might demonstrate that possibly you possesed a hardware token that contained a unique private key that existed no place else in the world (or say a file that resides on your harddisk containing the private key). The use of the private key to generate a digital signature establishes one factor authentication as something you have.

This might be improved by having hardware tokens that contain a unique private key and require a unique PIN to be entered before they operate. Given that the characteristics of the hardware token can be established, then a digital signature by such a hardware token may be considered as demonstrating two-factor authentication (the token as something you have, and entering the correct PIN as something you know).

More complex tokens can require both a PIN and a biometric ..... for 3-factor authentication; the application of the digital signature (given that the characteristics of the token can be prooved) can demonstrate 1) something you have (the token), 2) something you know (correct PIN entered), 3) something you are (correct biometric entered).

Notice that the really critical issues about the level of trust with regard to authentication goes up with the factors involved .... and has nothing at all to do with cretificates and/or the concept of trust propagation.

With regard to legal, trusted signature .... the issues of demonstrating intention and/or non-repudiation are a critical issue (independent of things like digital signatures, and quite definitly independent of of issues of trust propagation and certificates) as well as the level of trust in the authentication mechanism (i.e. number of factors, possibly evaluation of hardware token, etc .... again having no relationship at all with regard to trust propagation and certifictaes).

given the foundation for strong demonstration of authentication and strong demonstration of intention and non-repudiation .... then one might consider certificates as mechanism for trust propagation for the benefit of relying party strangers (assuming an unconnected, offline infrastructure where the relying party stranger has no prior knowledge of the signing entity and/or no recourse for contacting the certifying authority) .... but the existing certificates do little or nothing to address the level of trust in the authentication mechanism and/or the level of trust in the non-repudiation mechanism.

a few past threads related to 3-factor authentication:
https://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/aadsm14.htm#23 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?

a few past threads specifically related to non-repudiation:
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation

lhonkane@xxxxxxxx on 10/31/2003 2:18 am wrote:

http://www.fineid.fi/default.asp?todo=setlang&lang=uk
this is a link to an interesting multimedia presentation on the Finnish government - banks - telcos joint project on using the government produced certificate on bank and telco issued cards.

Pekka Honkanen

-----Alkuperäinen viesti-----
Lähettäjä: Anders Rundgren [mailto:anders.rundgren@xxxxxxxx]
Lähetetty: 30. lokakuuta 2003 23:46
Vastaanottaja: internet-payments
Aihe: On-line signature standards

Here is some information related to Internet payment gathered from a poll made to the IETF-PKIX, IETF-SMIME, and the OASIS PKI-TC lists regarding the current state of on-line signature standards

=====================================================
There are apparently no standards and nothing in the works either with respect to signing on-line data on the web using Internet browsers.
=====================================================

Since web-signing is today [*] used by many, many, more people and organizations than there are users of signed e-email, I remain puzzled.

Is the PKI community really just a bunch of "nerds", mostly out of touch with the needs of the market?

And what good is a legal framework like the EU signature directive, intended to address "legal interoperability" if there is no interoperability in the technical solutions?

"The truth is [still] out there" to travesty a famous TV series.

However, my request spurred quite a lot of interest, so I believe that web- signing really is a thing that finally will be standardized. The question is more by who, as the major interest is really coming from the public sector, not from commercial entities like banks, that rather protect their investments in proprietary solutions. I personally plan to pusue such a task in W3C or in OASIS in case somebody is interested.

*] Like Scandinavian banks having > 0.5M of users. All current systems rely on entirely proprietary mechanisms. Most of the vendors even require NDAs for getting the documentation.

Anders Rundgren


VS: On-line signature standards

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/02/2003 08:03 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "'internet-payments'" <internet-payments@xxxxxxxx>,
    "pekka honkanen Welho" <lhonkane@xxxxxxxx>
Subject: Re: VS: On-line signature standards
But the only business purpose for certificates is for trust propagation associated with offline operations (where the relying party has no access to the real and timely information and therefor must make do with stale, static copies).

In the payment card scenario .... the merchant
  1. doesn't need the public key since it relies on the issuer for an online authentication & authorization
  2. the account number is already part of the transaction
  3. the account number already routes to the issuer
  4. doesn't need the issuer's signature on a ceritifcate since it doesn't need the contents of the certificate and therefor doesn't need a signature on something that it doesn't need
the merchant needs what's defined in X9.59 ... i.e. the data elements of the transaction and the customer's signature on the transaction ... all for forwarding to the issuer.
https://www.garlic.com/~lynn/x959.html#x959

so that is the 3rd party scenario.

also, as previously outlined .... the issuer doesn't need a copy of the issuer's certificate since the issuer already has the original and therefor it is redundant and superfluous for the customer to send a copy of something back to the issuer where the issuer has the original. If you prefer, the description of of how to handle zero byte certificates;
https://www.garlic.com/~lynn/aepay2.htm#position

also how it is redundant and superfluous to transmit relying-party-only certificates back to the relying-party (i.e. since the issuing institution already had the original)
https://www.garlic.com/~lynn/subpubkey.html#rpo

however the original thrust of the postings was to do with the foundations of trust ... as opposed to the foundations of trust propagation .... certificates are a method of trust propagation .... which is a separate business issue from establishing trust with regard to the validaty of electronic signatures.

A digital signature can be viewed as part of a business process for establishing the basis for the business process of electronic signatures, specifically the authentication part of establishing electronic signatures. Legal electronic signatures require (at least) things like
  1. authentication
  2. non-repudiation
  3. demonstration of intent and/or agreement
Authentication can be thought of in the context of three-factor authentication:
  1. something you have
  2. something you know
  3. something you are
So an electronic signature trust taxonomy
  1. authentication
    • something you have
    • something you know
    • something you are
  2. non-repudiation
  3. demonatration of intent and/or agreement
Now I see no situation where certificates play in the above trust taxonomy.

Assuming the basis for electronic signature trust operation can be established .... then in business process that need trust propagation in an offline environment where the relying-party has no other recourse, then one could conjecture the business process need for a stale, static credential like a certificate. previous posting
https://www.garlic.com/~lynn/aadsm15.htm#32

As per above .... it is pssobile to establish a digital signature infrastructure which can be used to infer something you have (like an encrypted private key software file or a private key hardware token) and possibly something you know (an PIN to access the private key that performs the digital signature). There is even a possibility for digital signature infrastructure that can be used to infer something you are (i.e. a certified hardware token that does digital signatures, but requires biometric input). Again there is no concept of a certificate and trust propagation associated with the use of digital signatures to establish the basis of authentication as part of a electronic signature trust business process. Do you know where certificates infrastructures mention three-factor authentication and/or anything to do with something you have and/or something you know operations? Certificates have to do with the business process of trust propagation for offline environment where the relying party has no other recourse. They appear to have little or nothing to do with the actual business process of trust and establishing the legal acceptable basis for business process of electronic signatures.

My perception is that e-government is an attempt to establish an online infrastructure, where-as certificates address the business process of establishing an offline infrastructure (where there is no recourse to online and/or timely information). One might even make that the assertion that demanding the creation of constructs that satisfy business requirements for offline infrastructure only confuses and probably actually obstructs the establishment and understanding of what the fundamental constructs are needed for online business processes.

anders.rundgren@xxxxxxxx on 11/2/2003 2:23 am wrote:
No, they work as a convenient "handle" to both the citizen and to the issuers using various revocation mechanisms. To have a unique relation with thousands of authorities is impossible from an economic point of view no matter how good it may be.

But there is indeed a certain redundancy in certificates! It would be technically enough that a signature contained

1. the public key
2. a claimed ID (account number
3. a link to the issuer
4.the signature itself

But this reduction of data would not have such a dramatic impact as far as I can see. Well, it would delay the introduction of e-government services a few years of course.


VS: On-line signature standards (slight addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/02/2003 09:15 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: 'internet-payments' <internet-payments@xxxxxxxx>,
pekka honkanen Welho <lhonkane@xxxxxxxx>
Subject: Re: VS: On-line signature standards (slight addenda)
a little more clarification for electronic signature taxonomy
  1. authentication
    • something you have
    • something you know
    • something you are
  2. non-repudiation
  3. demonstrate intent and/or agreement
The typical, traditional use of certificates are to indiscriminately broadcast them at the slightest propagation. As a result, there can be hundreds or thousands of copies of a particular certificate floating around the world.

Digital signatures as part of a authentication business process is looking for being able to uniquely infer
  1. something you have
  2. something you know
  3. something you are
now, if I have a hardware token that contains a private key and performs digital signatures .... and the hardware token can be certified as containing a unique private key and highly resistant to allowing a duplicate of that private key to be copied .... then when a digital signature is performed, then one might infer that it is in the possession of the individual owning the hardware token. From the appilcation of a digital signature, one might infer that it is in the possession of the token owner and therefor infer one-factor authentication, something you have.

The possession of a digital certificate doesn't carry the same weight, since it has been established that there are possibly thousands of copies floating around the world .... so it can't be the basis of one-factor, something you have authentication.

Now, if the hardware token is also certified to work in a specific way when a PIN is supplied, then it might be plausable to infer two-factor authentication when such a hardware token performs a digital signature, aka two-factor authentication; something you have (the hardware token) and something you know (the PIN for the hardware token). As a side-note, such a PIN is not a shared-secret since it need not be divulged to any other entities (than the token owner). The PIN and token may be assumed to be unique as the basis for establishing two-factor authentication; something you have and something you know.

The possession of a digital certificate doesn't carry the same weight, since it has been established that there are possibly thousands of copies floating around the world ... so the contents of a digital certificate can't be the basis of two-factor, something you have and something you know, authentication.

Similarly, the existance and/or possession of a certificate also doesn't infer something you are authentication.

The assertion is that certificates are part of support of an offline paradigm, providing stale, static copies of information for trust propagation.

VS: On-line signature standards

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/02/2003 10:11 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: 'internet-payments' <internet-payments@xxxxxxxx>,
pekka honkanen Welho <lhonkane@xxxxxxxx>
Subject: Re: VS: On-line signature standards
anders.rundgren@xxxxxxxx on 11/2/2003 9:29 am wrote:
Lynn,
To convert everything into a payment system is not a good way to discuss things. Identity <<>> Payment.

So an "issuer" in the ID-world has no reason to ever get client signatures as the only thing an issuer of IDs can vouch for is the binding between a "name" (a.k.a. account number) and a public key. That means that in an ID-world using TTPs the transferal of the user's public key as a part of a "transaction" is indeed necessary. To use account numbers for issuer lookup does not work in an ID-world either as the very same account number (citizen name) may be issued. That is, my name is not "Anders Rundgren, cid=4545454, @bigca", only "Anders Rundgren, cid=4545454".


hum, lets see, what is the mailing list ... hum, it seems to be internet-payments?

to the extent the previous posts had a discussion of a specific payment related scenario .... it was in response to a specific example you gave regarding possible compression of information in certificates.

the original post and the majority of the subsequent posts was discussing
https://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)

basis for valid acceptable electronic signature. as mentioned before .... I outlined previously .... there was a discussion of authentication .... specifically a commonly acceptable taxonomy for authentication, namely three-factor authentication:
  1. something you have
  2. something you know
  3. something you are
within the context of a acceptable legal electronic signature having to do with
  1. authentication
  2. non-repudiation
  3. proving intent and/or agreement
so I strongly assert that
  1. authentication
    • something you have
    • something you know
    • something you are
  2. non-repudiation
  3. proving intent and/or agreement
is not converting everyting into a payment system. It is trying to establish the basis for discussing, valid, legal electronic signatures.

I possibly mistakenly assumed that with the subject line of on-line signature standards that just plausably there was some room for discussing valid, legal, electronic signatures?

Futhermore, given that this particular mailing list is specifically titled internet-payments .... it wouldn't be completely unacceptable to include a single example of electronic signatures within the context of a payment system?

The subject of identity is yet to come up?

VS: On-line signature standards

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/02/2003 01:49 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "'internet-payments'" <internet-payments@xxxxxxxx>,
    "pekka honkanen Welho" <lhonkane@xxxxxxxx>
Subject: Re: VS: On-line signature standards
anders.rundgren@xxxxxxxx on 11/2/2003 10:58 am wrote:
Lynn.
The problem in my opinion is that your ideas regarding the non-utility of certoficates is maybe another discussion than the legality of signatures. To the latter I have a fairly basic comment: Before the advent of signatures, legality in the e-world was not a major issue. To require three- factor authentication is fine but unlikely to work very as the basis for legal actions as you cannot trace the DNA of signer in the signature, sort of. Biometric have one possibly good application and that is as a protection against misuse of a signature device. Like featured on some of the more advanced HP PDAs. It may also work in bank vaults etc. However, as a over- the-net mechanism I believe biometrics is no good.
Anders


Again, I believe you are grossly mis-interpreting what I posted.

I've constantly asserted that certificates were originally designed to address trust propagation in an offline environment and continue to be used to address situations where the relying party has no other recourse for the information.

I've also repeatedly provided numerous examples of having been somewhat instrumental in the currently deployeed major use of certificates:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
https://www.garlic.com/~lynn/subpubkey.html#sslcert

So I can't understand your reference/assertion to my ideas regarding the non-utility of certificates.

So hopefully not to miscontrue you statements as red herrings met to obfuscate and misdirect .... i assert that in order to establish valid online signatures .... you first need to relate a valid online signature to a valid electronic signature. I assert that the paradigm and framework for valid electronic signature (needed to establish a valid online signature) is
  1. authentication
    • something you have
    • something you know
    • something you are
  2. non-repudiation
  3. proove intent and/or agreement
and that digital certificates are extraneous to that core paradigm. digital certificates can be added to a valid electronic signature framework as part of trust propagation for relying parties in an offline environment and/or relying parties have no other recourse to the information.

so another possible misdirection is the statement about "over-the-net" mechanism, I believe biometrics is no good.

I'm somewhat assuming that you are relating biometrics and something you are authentication. so, to examine your assertion, lets further expand the valid, legal, electronic signature taxonomy:
  1. authentication
    • something you have
    • something you know
      • shared-secret
      • non-shared-secret
    • something you are
      • shared-secret
      • non-shared-secret
  2. non-repudiation
  3. poove intent and/or agreement
so a possible two-factor authentication implementation something you have and something you know. One such existing traditional mechanism is a magstripe debit card and a shared-secret PIN. The debit card is inserted, prooving something you have and you enter a PIN (which is passed to the processor) prooving something you know. Separate from the paradigm/taxonomy analysis, a vulnerability analysis has crooks skimming both the magstripe data from the card and the PIN ... and creating counterfeit magstripe cards with the PINs written on them. Obviously such static data technology implementation doesn't translate well to on-the-net; not because of some flaw in the taxonomy but flaws in the technology and implementation.

Another vulnerability of the current infrastructure is (because possibly of shared-secret human factors reason) a significant percentage of the population write the PIN number on the card. That significantly defeats the attempt to have two-factor authentication (separate something you have and something you know); but it is a fact of life given the existing proliferation of shared-secret infrastructure and the related human factors.

So one proposal is to replace PINs with fingerprints (especially for the large percentage of the population that write their PIN on the card). So the comparison becomes for this particular vulnerability scenario ... which is easier:
  1. easier for the crooks (existing major fraud) to skim the magstripe information and use a video camera to record the PIN entry, produce a counterfeit magstripe card with the PIN written on it, and then perform fraudulent transactions with the counterfeit card and the recorded PIN
  2. easier for the crooks (existing major fraud) to skim the magstripe information and use a video carmea to record the fingerprint entry, produce a counterfeit magstripe card with the fingerprint written on it, and then perform fraudulent transactrions with the counterfeit card and the recorded fingerprint.
And for the other vulnerability scenario where a crook steals the actual card, which is easier:
  1. earier for the crooks to steal a real card with the PIN written on it and perform a fraudulent transaction with the real card by entering the PIN recorded on the card
  2. easier for the crooks to steal a real card, possibly with latent fingerprints, and perform a fraudulent transaction with the real card and lift the latent fingerprint, produce a counterfeit fingerprint from one of the latent fingerprints on the card and enter the counterfeit fingerprint during the fraudulent transaction.
I assert in both cases, that for the comparison of this particular case of two-factor authentication .... the something you are scenario is more difficult for the crooks than the something you know scenario.

So the financial industry biometric standard, x9.84 talks about the security needed for transmitting a biometric value over a network (from point of entry to backend processing) and the necessary security precautions necessary to protect the biometric value from both external attacks like evesdroppers as well as internal attacks (eimployees, business operations). It describes fairly stringent security .... which I assert would be pretty much the same whether it is a private VAN or a public internet operation. The fundamental issue is that PINs, biometrics (and even account numbers) are effectively shared-secrets .... anybody evesdropping (external attacks or internal attacks) and harvesting the information may be able to use it for fraudulent transactions.

A big concern is that PINs as shared-secrets allows for value change in cases of compromise while it is quite a bit harder to achieve a change when a biometric value has been compromised.

So lets go back and look at the reference to being able to infer one, two, and/or three factor authentication based on a digital signature ..... warning slight topic drift I've observed frequent semantic confusion because the "label" given to private key encryption of a secure hash includes the word signature, which has significantly different meaning when used in a legal sense. A digital signature is not a valid, legal electronic signature ... even though the two terms happen to share the word signature. A "digital signature" can be used to infer something about one, two, and/or three factor authentication as part of a valid electronic signature paradigm .... but a "digital signature" is not a valid legal electronic signature (and to go even further afield .... a digital certificate is even less a valid, legal electronic signature than a digital signature is). A few past refs to semantic confusion
https://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/2003k.html#6 Security models

I assert that I can certify some component (like a hardware token) that will execute a digital signature .... and from the existance of that digital signature, it can be inferred that somebody possesses that token (one factor authentication, something you have).

Such hardware tokens can be built and certified that also provides the grounds for inferring something you know and/or something you are. Furthermore, the construction and certification of such a component can be done that the something you know and/or something you are changes from a shared-secret paradigm (as discussed above) into a non-shared-secret paradigm.

The construction and certification of such a token can be such that based on the token generating a digital signature, it can be inferred that the correct PIN was entered (something you know) and/or an acceptable biometric evaluated (something you are). It is not necessary to transmit the token, the PIN< and/or the biometric over the network. The device can be constructed in such a way .... that from the existance of a particular digital signature ... that the token was in somebody's possession (something you have authentication) and possibly that the entered the correct PIN (something you know authentication) and/or provided the correct biometric for the token to evaluate (something you are authentication).

I've repeatedly asserted that a digital signed protocol can be defined where there is some information that carries a digital signature.

The level of trust in that digital signature can be based on a whole set of business process factors that are totally independent of the protocol carrying the digital signature. The trust and weight given that digital signature can be an issue of the construction and certification of the device and environment creating the digital signature ... independent of the digital signature itself (as well as independent of whether any number of associated digital certificates happen to exist).

Furthermore, I assert with technology like "match on chip", the use of biometrics can be done as a non-shared-secret paradigm and w/o any biometric information flowing over any network. The issue of the level of trust with regard to one factor, two factor, and/or three factor authentication and the method and environment for generating PINs and/or biometrics is related to the technology used .... and can be totally independent of the protocol for carrying a digital signature and/or whether or not there is a redundant, superfluous, stale, static certificate carried along also.

Aka ... i assert the issue of something you are authentication can be implemented as a business process involved in certifying a specific kind of digital signature generating device and transparent to the actual authentication transport (aka whether or not there has been something you are authentication is inferred from the type of device that generates the digital signature, in much the same way that something you have authentication is inferrred from the device that generates the digital signature).

VS: On-line signature standards

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/02/2003 02:22 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "'internet-payments'" <internet-payments@xxxxxxxx>,
    "pekka honkanen Welho" <lhonkane@xxxxxxxx>
Subject: Re: VS: On-line signature standards
oh, i before I forget ... some misc. passed discussions of biometrics, shared-secrets, and non-shared-secrets:
https://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm10.htm#biometrics biometrics
https://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
https://www.garlic.com/~lynn/aadsm10.htm#bio5 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#bio7 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#bio8 biometrics (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
https://www.garlic.com/~lynn/aadsm14.htm#23 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay11.htm#22 FBI Probing Theft of 8 Million Credit Card Numbers
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/99.html#189 Internet Credit Card Security
https://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
https://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#61 I-net banking security
https://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
https://www.garlic.com/~lynn/2002f.html#45 Biometric Encryption: the solution for network intruders?
https://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates
https://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ?
https://www.garlic.com/~lynn/2002m.html#14 fingerprint authentication
https://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2003e.html#47 Public key and the authority problem
https://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
https://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003m.html#0 Passwords multiply as users' rage rises
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?

FAQ: e-Signatures and Payments

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/12/2003 10:16 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>
Subject: Re: FAQ: e-Signatures and Payments
Basic beginning security 101 is that anytime that you fail to have end-to-end security and integrity of the operation ..... you open things to failure and fraud (this can because that the security and integrity mechnaims doesn't follow the complete end-to-end operation of the transaction and/or the integrity and authentication mechanisms are separated from the actual transaction and/or both).. financial industry x9.59 standard (to preserve the integrity of the financial infrastructure for all electronic retail payments in all environments) X9.59 has end-to-end transaction authentication and integrity operation. I think that you've confused authentication, integrity and reliable signatures again. Note that the X9.59 standard defines the necessary transaction fields for a reliable end-to-end signed transaction. The actual standard doesn't define the signing mechanism.

The appendix of the X9.59 standard contains a mappings of the X9.59 standard to existing payment infrastructures and signing mechanisms. One such example mapping is:
https://www.garlic.com/~lynn/8583flow.htm
lots more references to X9.59 (including pointer to how to obtain the actual X9.59 standard document):
https://www.garlic.com/~lynn/x959.html#x959

The X9.59 does define the fields in terms of ASN.1 encoding .... but there is also work on defining the fields in terms of XML encoding. The issue of ASN.1 encoding vis-a-vis XML encoding, is that the end-points needed to establish and verify the integrity of the transaction, but also allow the actual data fields to be carried in various formats defined by the actual payment network (w/o unnecessary duplication of information and the associated inefficiency). At the time of the standard, ASN.1 provided for deterministic encoding of values i.e. given that the originating end-point and the terminating end-point were going to encode the same values, they had to come up with the same bit-representation (aka the objective was to allow that the originating end-point and the terminating end-point arrive at the identical encoded bit-representation to prove values had not been altered during transmission and/or processing). There was work in FSTC (the organization sponsoring this mailing list) on FSML which provided an extension to XML for deterministic bit encoding of values for the same reason done by X9.59 .... that the originating end-point and the terminating end-point could arrive at the same bit-representation (w/o mandating the format of the values during transmission). The FSML work has since been encorporated into XML signature work for supporting deterministic encoding rules. An example tagged encoding is included in the above appendex URL reference mapping. There is proposal that X9.59 standard now be updated to include both ASN.1 encoding and XML encoding (with the enhanced deterministic encoding rules from FSML).

random past authentication and/or end-to-end transaction threads that you participated in:
https://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
https://www.garlic.com/~lynn/aadsm4.htm#10 Thin PKI won - You lost
https://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
https://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
https://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
https://www.garlic.com/~lynn/aadsm7.htm#pcards5 FW: The end of P-Cards?
https://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
https://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate? (addenda)
https://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm11.htm#1 Basic credit-card payment question
https://www.garlic.com/~lynn/aadsm11.htm#20 IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#29 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm11.htm#30 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm11.htm#31 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm11.htm#38 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
https://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
https://www.garlic.com/~lynn/aadsm12.htm#4 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#6 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#7 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction?
https://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt
https://www.garlic.com/~lynn/aadsm12.htm#42 draft-ietf-pkix-warranty-extn-01.txt
https://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#53 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#56 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP
https://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
https://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
https://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories
https://www.garlic.com/~lynn/aadsm14.htm#6 The case against directories
https://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
https://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
https://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
https://www.garlic.com/~lynn/aepay4.htm#visaset2 Visa Delicately Gives Hook to SET Standard
https://www.garlic.com/~lynn/aepay6.htm#gaopki3 GAO: Government faces obstacles in PKI security adoption
https://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption
https://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate
https://www.garlic.com/~lynn/aepay6.htm#dspki2 use of digital signatures and PKI
https://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
https://www.garlic.com/~lynn/aepay6.htm#userauth2 MS masters NC mind-set (authentication is the key)
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay10.htm#17 Visa 3-D Secure vs MasterCard SPA Whitepaper (forwarded)
https://www.garlic.com/~lynn/aepay10.htm#34 some certification & authentication landscape summary from recent threads
https://www.garlic.com/~lynn/aepay10.htm#35 some certification & authentication landscape summary from recent threads
https://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards
https://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
https://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#69 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#70 Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#71 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
https://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#2 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process, payment, authentication and identification

--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm

anders.rundgren@xxxxxxxx on 11/12/2003 9:15 am wrote:

Maybe it is a bad idea to respond to your own postings but I give it a try -:)

A logical consequence with the stuff below is that things like EMV, and X9.59 has no bright future as they cannot support a reliable signature mechanism except on a cryptographic level. But 3D Secure can! And 3D Secure is just the first shot in this direction.

Stay tuned
/a
----- Original Message -----
From: Anders Rundgren
To: internet-payments
Sent: Wednesday, November 12, 2003 09:08
Subject: FAQ: e-Signatures and Payments

Extract from an FAQ for an on-line e-signature standards proposal in progress:
...
That is, DRY Signatures are neither useful nor intended to be used where the signature requester is unknown or maybe even untrusted by the user. Does not the "trusted service provider" limit usability? Although this may be considered as a serious disadvantage of DRY Signatures, the same limitation is actually applicable to just about all on-line systems, as both on-line "receipts" and automatic client-side archival of "evidence" are usually missing. That is, the user must indeed rely on the service provider to cater for trustworthy handling of the data involved. Newer on-line payment systems, like VISA's 3D Secure, address this in a very elegant fashion by instead of requiring users to sign transactions directly to possibly unreliable merchants, instead routes payment requests to the user's own trusted and known bank (issuer). By doing that, users can be reasonably assured that transaction requests are archived, and that signature requests will always be in the same format as well as in a language that the user understands. This scheme even allows fraudulent merchants to be automatically blocked by the bank.

Regards
Anders Rundgren (Editor)

FAQ: e-Signatures and Payments

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/12/2003 09:20 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments <internet-payments@xxxxxxxx>
Subject: Re: FAQ: e-Signatures and Payments
i think you have it confused again.

x9.59 defines fields that require verified integrity and authentication. so does the e-check project done by FSTC.

you can show x9.59 transactions in a user-friendly way ... sign transactions in ASN.1 (and soon XML and send them in ASN.1, XML, 8583, ach, etc.

as i outlined in the previous posting and numerous times previously in past treads .... X9.59 (and e-check) define fields and encoding mechanism for supporting verifying the integrity of the tranasaction as well authenticating the transaction.

as I mentioned in the previous posting and numerous times previously in past threads ... x9.59 (and e-check) allow the fields to mapped into existing infrastructures and then be reconstructed for intetrity verification and authentication.

security 101 teaches end-to-end security and integrity of operation. when integrity of operation is broken .... either with missing and/or fragmented security and possibly multiplicity of different operations .... then at least complexity and opportunity for fraud and additional failure modes are increased and/or introduced. Simple 101, kindergarten security principles.

For example, separating the actual transaction operation from the authentication and integrity checking might result in the transaction operation being executed independently of the authentication and integrity checking. Trying to match up transaction operation which might be done in one network on one time-scale .... with authentication and integrity operations that is done in a completely different network and different time-scale creates opportunities for things being out of sync, having different failure modes, extreme complexity of matching up operations in one context with operations in a totally different context. One of kindergarten, security 101 things tend to be KISS .... the less KISS and the more complex .... the more prone the infrastructure is to additional failure (and fraud) modes.

All other things being equal .... KISS always wins out over complexity for the sake of complexity. Adding a electronic signature to an existing 8583 transaction .... so the integrity of the 8583 transaction can be checked and authenticated by the issuing bank .... significantly beats out any process that would send a 8583 transaction via one infrastructure .... and any sort of electronic signature via a totally different infrastructure .... and then expect that the issuing financial institution has to match up authentication and integrity material with a totally independent 8583 transaction that is being processed via totally different infrastructure.

For instance, lets say I walk in the store and do an X9.59 transaction with a chipcard. The issuing financial institution gets an electronic signature along with the 8583 transaction, check the authentication and integrity of the transaction, checks the other information related to the transaction and sends back a real time approval. The merchant then lets me walk out with the merchandise.

I would assert that any change that you would make to the above description makes it less KISS, more complex, and less secure.

anders.rundgren@xxxxxxxx on 11/12/2003 12:57 pm wrote:

The problem with this is the unnecessary narrow definition of end-to -end security.

# Going through a possibly fraudulent merchant's systems to reach my bank is indeed end-to-end security but pretty useless such unless the thing you sign is exactly what is sent to the bank. This is for many reasons not very practical. At least not on the net. Using 3D Secure et al you don't have this restriction. I.e. you can show transactions in a user-friendly way but send transactions in ASN.1 or XML. Still signatures can be verified towards the transaction data if you have the transaction- to-viewable-format transformation logic.

# If I can't trust my bank for performing a transaction on my behalf I could well do without the bank altogether. Anyway this is what hundreds of millions people do on their on-line banks so I can hardly see that it is impossible or security-wise wrong.

Anders

FAQ: e-Signatures and Payments

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/13/2003 08:39 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "internet-payments" <internet-payments@xxxxxxxx>
Subject: Re: FAQ: e-Signatures and Payments
OK, the requirement for X9.59 was to insure the integrity of the financial infrastructure for all electronic retail payments ... that is ALL as in ALL. So there was a demo of X9.59 at 1999 BAI in webstore configuration:
https://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show

so lets say there are paranoid people that don't trust the merchant terminal .... then I assert the operation of X9.59 with cellphone/PDA with the cellphone/PDA using BLUETOOTH or WI-FI (or other wireless interface) to the merchant terminal ... has exactly the same process steps as a personal computer at home using the Internet (aka personal device to merchant, merchant device to financial infrastructure).

the two issues with regard to merchant terminal have been covered in past posts 1) is what you see, what you sign and 2) skimming any entered "what you know" or "what you are" authentication information. This is also referenced is some number of FINREAD related previous posts (appended).

I wasn't referring to whether or not banks were used as trusted providers ... the refernece and the accompanying description was about the actual flow of the transaction and the actual flow of the authentication and integrity information.

Of course banks can be trusted providers

The original statement (and subsequent statements) were with respect to security protcool analysis and elementary security guidelines.

The original statement (and subsequent statements) was that (all other things being equal), that if the process isn't an integral end-to-end operation then it is The above assertions about elementary security principles are independent of whether banks as trusted providers are involved or not. To that extent, comments about banks as trusted providers are somewhat orthogonal and obfuscation with respect to elementary security principles.

minor reference some EMV stuff
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?

past threads (that you participated in) which involved FINREAD
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
https://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm15.htm#38 FAQ: e-Signatures and Payments
https://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
https://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper

other related threads mentioning FINREAD:
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
https://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
https://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature
https://www.garlic.com/~lynn/2003j.html#25 Idea for secure login
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?

--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm

anders.rundgen@xxxxxxxx on 11/13/2003 12:45 am wrote:
Sure, X9.59 or EMV is problably just fine at least as long as you trust the terminal where you insert your chip-card. However, on the Internet using a web-store X9.59 end-to-end is anything but ready for prime-time. And the interesting thing is that the Internet approach (3D) MAY one day find its way down to the brick-and-mortar shop as it makes no sense to long-term have multiple infrastructures for payments.

I guess we can agree on this last line at least? And then agree on that it will be "the battle of the payment systems". Or has somebody already won? I don't think so.

>I would assert that any change that you would make to the above
>description makes it less KISS, more complex, and less secure.

To me using banks as trusted providers, authenticators and archievers seems like KISS as this is what banks have been doing since day #1.

/anders


AADS Postings and Posting Index,
next, previous - home