Misc AADS & X9.59 Discussions


AADS Postings and Posting Index,
next, previous - home



DNSSEC (RE: Software for PKI)
3D Secure Vulnerabilities?
3D Secure Vulnerabilities?
DNSSEC (RE: Software for PKI)
Seeking Privacy Online, Even as Security Tightens
Software for PKI
Software for PKI
Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
A PKI Question: PKCS11-> PKCS12
A PKI Question: PKCS11-> PKCS12
A PKI Question: PKCS11-> PKCS12
A PKI Question: PKCS11-> PKCS12
CFP: PKI research workshop
CFP: PKI research workshop
CFP: PKI research workshop
CFP: PKI research workshop
CFP: PKI research workshop
CFP: PKI research workshop
CFP: PKI research workshop
CFP: PKI research workshop
CFP: PKI research workshop
CFP: PKI research workshop
CFP: PKI research workshop
CFP: PKI research workshop
Small/Secure Payment Business Models


DNSSEC (RE: Software for PKI)

From: Lynn Wheeler
Date: 11/09/2001 04:55 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, lynn.wheeler@xxxxxxxx
Subject: Re: DNSSEC (RE: Software for PKI)
i managed to fat finger some number of the URLs in the previous note ... they've been corrected in the version at:
https://www.garlic.com/~lynn/aadsm8.htm#softpki19

3D Secure Vulnerabilities?

From: Lynn Wheeler
Date: 11/09/2001 06:26 PM
To: "Richard D. Brown" <rdbrown@xxxxxxxx>
cc: internet-payments@xxxxxxxx
Subject: RE: 3D Secure Vulnerabilities?
even more so ... between the draft and the published version ... there was significant "cleaning" of the issues around public-key, private-key, digital-signatures, certificates, etc. Drafts right up to the final document included keys, signatures and certificates in various portions of the ASN.1 specification ... all of that got clieaned.

the x9.59 doesn't have integration constraints per se ...

the requirements given to the X9A10 standard working group for X9.59 was that it be applicable to all account-based payments and preserve the integrity of the financial infrastructure. There was a great deal of effort that went into the standard in attempt to make if applicable to all account-base payments and preserving the integrity of the financial infrastructure.

rdbrown@xxxxxxxx on 11/9/2001 wrote:
Actually, having reviewed the draft document, it's true that the standard does not mandate any specific algorithm. However, there are so many references in the normative text to 'public-key', 'private-key', 'signature'... that it certainly implies the use of an asymmetric crypto-system, and more specifically, use of a public-key digital signature. But I can see, where you're coming from... ;)

Certainly, it would be possible to leverage X9.59 payment objects in a TVC context. However, X9.59 has integration constraints (i.e. adapting current ISO8583 infrastructures) that would defeat the main purpose/objective of TVC.

-RDB-


3D Secure Vulnerabilities?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/10/2001 01:37 PM
To: "Richard D. Brown" <rdbrown@xxxxxxxx>
cc: internet-payments@xxxxxxxx
Subject: RE: 3D Secure Vulnerabilities?
somewhat as an aside .... while there was a lot of work done on mapping/integration of X9.59 into payment cards .... debit/credit, x9.15/iso8583, etc .... providing seemless, end-to-end, authenticated, secure transactions ..... "all account-based transactions"; preserving the integrity of the financial infrastructure .... also involved looking at many of the financial transaction infrastructures ...

debit
credit
ATM
ACH
"e-check"
fedwire
swift
somewhat similar being able to help author the NACHA pilot specification for internet debit transactions:
https://www.garlic.com/~lynn/x959.html#aads

we also talked to fedwire and swift and was able to help author swift proposal.

the x9a10 group took its charter seriously for a standard that could be applicable to all account-based transactions and preserve the integrity of the financial infrastructure.

with regard to using FIPS186-2, EC/DSA federal standard for authentication ... there was a minor characteristic noted that such a digital signature could also help in identify replay-attacks & duplicate transactions. A FIPS186-2 federal standard for authentication effectively creates a unique signature for every signing .... even if the same exact data is signed multiple times. Different transactions that otherwsie look the same will have different authentication signatures. Duplicate transactions will have the same exact signature.

one of the side issues of doing a standard is that it isn't vendor proprietary. that obviously can have a lot of advantages to customers but standards can have both their upside & downside. vendor exclusivity can have the characteristic that there is market entity with extra justification to champion and fund deployment. ... which i guess could be considered the opposite of open-systems and interoperability.

DNSSEC (RE: Software for PKI)

From: Lynn Wheeler
Date: 11/11/2001 11:58 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: DNSSEC (RE: Software for PKI)
and from the archives on a long ago, far away project ... price has come down some ....


Date: 1 July 1985, 08:17:15 MDT
To: WHEELER

Lynn,
re: your questions about the public key encryption unit

The Racal-Milgo Datacryptor III uses a AMD DES chip plus some proprietary logic for exchanging master keys using a public key approach. The master keys are then used to encrypt the working keys which are actually used for data encryption. I have run the off the shelf units at 128kb full duplex through the V.35 interfaces contained in the unit. They cost about $3,200 each, single unit price.

I have to emphasize they are link level encryptors (e.g. level 1) rather than level 2 (e.g. only the data encrypted with addressing in the clear). They won't do you much good for "session" or "file" encryption. The public key synopsis goes something like this -

1. At install time, two 60 digit prime numbers are acquired and retained in storage. The 'seeds' are developed by a combination of an operator pressing a button to sample a clock source along with internal logic.
2. When a operator wants to move a master key online, he asks the remote end for a one-time E key (56 bits plus 8 parity bits).
3. The remote end uses the two 60 digit prime numbers (with their 120 digit product) to create a E key and a D key. They are "mathematically related to the prime numbers and to each other" to quote the Racal documentation.
4. The E key can't be used for decryption and the D key can only decrypt what has been encrypted with the E key.
5. The remote end retains the D key and sends the E key to the 'requestor'.
6. The local end generates a new master key, encrypts it with the E key he just received, and sends it to the remote end.
7. The remote end decrypts the transfer with the D key he retained, they exchange a test message for verification, and exchange a new working key.
8. The E/D pair of keys are not reused. Each exchange of a master key causes a new pair to be created. The E/D pair never leave the boxes, and can't be read out or displayed. It takes about 8 seconds for the hardware to do the decryption of the received master key using the D key previously retained.



anders.rundgren@xxxxxxxx on 11/9/2001 12:19 pm wrote
These DNSSEC servers will not be practical until HW-crypto support is down in the $100 region. This may take another 5 years or so. It is driven by the B2B market that needs such servers as well.


Seeking Privacy Online, Even as Security Tightens

From: Lynn Wheeler
Date: 11/12/2001 10:31 PM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: cryptography@xxxxxxxx, dcsb@xxxxxxxx
Subject: Re: Seeking Privacy Online, Even as Security Tightens
... blast from the past.
To: security@xxxxxxxx
Subject: Re: The Electronic Communications Privacy Act
Date: Wed, 13 May 87 15:07:03 EDT
From: Henry Mensch <henry@xxxxxxxx>

This is what the MIT community (in general) was told about how this law affects our work. It sounds to me like the ECPA is talking about BITNET also. (Of course, the Act has no clue about "ownership" of data--they don't ever seem to define it).

This is a copy of a letter published in Tech Talk. Anyone who did not read that memo should look read it. Be sure to note that operators of electronic communication systems now have legal responsibilities for the privacy of data.

[Thanks also to Joe Harrington who forwarded a copy. _H]

MEMORANDUM

To: The MIT Community
From: James D.Bruce, Vice President for Information Systems
Re: The Electronic Communications Privacy Act

The Electronic Communications Privacy Act of 1986 was enacted by the United States Congress in October of last year to protect the privacy of users of wire and electronic communications.

Legal counsel has advised MIT that its computer network and the files stored on its computers are covered by the law's provisions. Specifically, individuals who access electronic files without appropriate authorization could find themselves subject to criminal penalties under this new law.

At this time, we can only make broad generalizations about the impact of the Act on MIT's computing environment. Its actual scope will develop as federal actions are brought against individuals who are charged with inappropriate access to electronic mail and other electronic files.

It is clear, however, that under the Act, an individual who, without authorization, accesses an electronic mail queue is liable and may be subject to a fine of $5,000 and up to six months in prison, if charged and convicted. Penalties are higher if the objective is malicious destruction or damage of information, or private gain.

The law also bars unauthorized disclosure of information within an electronic mail system by the provider of the service. This bars MIT (and other providers) from disclosing information from an individual's electronic data files without authorization from the individual.

MIT students and staff should be aware that it is against Institute policy and federal law to access the private files of others without authorization. MIT employees should also note that they are personally liable under the Act if they exceed their authorization to access electronic files.


Software for PKI

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/16/2001 04:35 PM
To: "Housley, Russ" <rhousley@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: RE: Software for PKI
it was a multi part piece of logic

1) part one ... early X.509 Identify certificate work for offline credentials has morphed into several other forms

2) ... identity is useful for more than a single relying party

3) ... eliminating identity ... somewhat restricts the domain of offline credentials.

4) one of the morphs was into online relying-party-only credentials

5) it was possible to show that in the case of relying-party-only credentials, the relying-party-only certificates were unnecessary, superfluous, and redundant.

As before the nominal X.509 identify offline certificates could involve into other types of offline information binding credentials. However, many of the X.509 offline credential morphs for the online world could be shown that such credential was unnecessary, redundant and superfluous (when the online original of the information was being accessed).

In the case of a relying-party-only scenerio that was accessing the online, real time account information ... that contained the original of the relying-party-only certificate .... it was possible to show either

a) reduction of the appended relying-party-only certificate to zero bytes ... since the receiving relying party already had a copy of all the information in the relying-party-only certificate

b) eliminating the appended relying-party-only certificate ... since the receiving relying party already had the original of the relying-party-only certifciate.

replay of this same discussion in this newsgroup from august of last year
https://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability
https://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability

general thread on offline stale credential vis-a-vis online, real-time information:
https://www.garlic.com/~lynn/aadsm2.htm#techno digital signatures, technology experiments, and service operations
https://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss4 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
https://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#liex509 Lie in X.BlaBla...
https://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die
https://www.garlic.com/~lynn/aadsm5.htm#spki Simple PKI
https://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
https://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
https://www.garlic.com/~lynn/aadsm7.htm#rhose10 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose11 when a fraud is a sale, Re:Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
https://www.garlic.com/~lynn/aadsmore.htm#pressign President Clinton digital signing
https://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
https://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
https://www.garlic.com/~lynn/aepay3.htm#openclose open CADS and closed AADS
https://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate
https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 updates for (AADS) Relying-Party Certification Business Practices
https://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
https://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000.html#40 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000b.html#40 general questions on SSL certificates
https://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format standard
https://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
https://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#0 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???

rhousley@xxxxxxxx on 11/12/2001 6:20 AM wrote:
Lynn:

Good grief. You are a smart guy. Do you say these things just to provoke reaction?

There is nothing in X.509 or PKIX that warrants such statements.

The whole point of a public key certificate is to bind a public key to an identity. The form of the subject identity can be application specific. For example, to support S/MIME, the certificate binds an electronic mail address to the public key. To support a anonymous payment protocol, the certificate would likely bind the public key to an identifier

of the financial institution and an account number, where only the financial institution need know the identity of the account owner. This is

clearly the opposite end of the spectrum from QC defined in RFC 3039.

Do not condemn the public key certificate because one application makes use

of a different form of identity than another application.

Russ


Software for PKI

From: Lynn Wheeler
Date: 11/16/2001 04:50 PM
To: "Housley, Russ" <rhousley@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: RE: Software for PKI
... also, with respect to the other direction this thread has taken .... some of the business justification issues may be when force-fitting offline, non-identity credentials manufactured at some time in the past .... into environment that is directly accessing the online, real-time, non-stale, superset of the credential (the easily obvious is the financial institution case, that given only the account number ... the operation references the account record which contains the real-time, online, non-stale, superset of the credential).

rhousley@xxxxxxxx on 11/12/2001 6:20 AM wrote:
Lynn:

Good grief. You are a smart guy. Do you say these things just to provoke reaction?

There is nothing in X.509 or PKIX that warrants such statements.

The whole point of a public key certificate is to bind a public key to an identity. The form of the subject identity can be application specific. For example, to support S/MIME, the certificate binds an electronic mail address to the public key. To support a anonymous payment protocol, the certificate would likely bind the public key to an identifier

of the financial institution and an account number, where only the financial institution need know the identity of the account owner. This is

clearly the opposite end of the spectrum from QC defined in RFC 3039.

Do not condemn the public key certificate because one application makes use

of a different form of identity than another application.

Russ


Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/26/2001 01:45 PM
To: <pasward@xxxxxxxx>
cc: dcsb@xxxxxxxx, Kent Borg <kentborg@xxxxxxxx>,
"R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
there are two issues in an ATM:

1) the electronic security and
2) the physical security of cash

... aka ATMs besides doing ATM transactions ... also contain physical cash ... potentially on the order of thousand or more $20 bills.

the electronic security of a PC is somewhat questionable in the near term ... although it has the characteristic that some of the things that can be done ... can be done by the PC owner (i.e. the owner of the PC has some control over how little or how much security they are willing to employ).

for PC-banking ... there has been some work in the EU for the finread standard ... basically a hardware token along with a "secure" reader. The finread "secure" reader is somewhat like the atm/debit terminal at check-out counters .... it is spec'ed to have a particular kind of "security module", tamper evident standards, its own keyboard, and its own display. The process is that the customer uses their hardware token (in the case of current debit/credit a plastic card with magstripe), enters the PIN securely, the terminal securely displays the amount of the transactions, and the customer confirms the transactions.

The finread standard is similar to the check-out counter ATM/debit terminal ... but for consumer attachment to PCs ... and its for chip-cards. It has its own separate pin entry, and can have its own separate display. Virus's on the PC can't generate fraudulent transactions when you aren't looking ... it requires your hardware token and physical person interaction with the terminal/reader for potenailly every transaction of specific kind.

random finread refs:
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
https://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market.

the other part is enabling secure debit/ATM transactions in the open network environment. NACHA has done trials for secure transactions in the open network environment (the other part of the ATM/debit-POS is that the transactions flow over a closed network),

random refs:
https://www.garlic.com/~lynn/x959.html#aads
https://www.garlic.com/~lynn/aadsm6.htm#echeck Electronic Checks
https://www.garlic.com/~lynn/aadsm6.htm#aadsatm (certificate-less) digital signatures can secure ATM card payments on the internet
https://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
https://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
https://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm8.htm#3dvulner3 3D Secure Vulnerabilities?
https://www.garlic.com/~lynn/aadsm9.htm#3dvulner5 3D Secure Vulnerabilities?
https://www.garlic.com/~lynn/aadsmore.htm#nacha NACHA digital signature pilot
https://www.garlic.com/~lynn/aadsmore.htm#debitfraud Debit card fraud in Canada
https://www.garlic.com/~lynn/aepay6.htm#ecomich call for new measures: ICH would be glad to help
https://www.garlic.com/~lynn/aepay6.htm#userauth MS masters NC mind-set (authentication is the key)
https://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nacha Nacha reports mentions X9.59 payment protocol
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay7.htm#nachaxml Unified Modeling Language (UML) for NACHA Business Models & XML Project
https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 updates for (AADS) Relying-Party Certification Business Practices
https://www.garlic.com/~lynn/ansiepay.htm#aadsach NACHA to Test ATM Card Payments for Consumer Internet Purchases
https://www.garlic.com/~lynn/ansiepay.htm#atmdebit NACHA AADS ATM debit ... from tomorrow's american banker
https://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
https://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#36 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#37 Credit Card # encryption
https://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
https://www.garlic.com/~lynn/2001l.html#51 Security standards for banks and other institution

pasward@xxxxxxxx on 11/26/2001 8:10 AM wrote:
Perhaps I should clarify. The issue is not me per se, but the general problem of securing a PC to the level of an ATM. Otherwise, banking on it is unattractive. Banks exist on goodwill, and a PC-banking scheme that destroys that goodwill through insecurity is hardly a good thing.


Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/26/2001 02:44 PM
To: Kent Borg <kentborg@xxxxxxxx>
cc: dcsb@xxxxxxxx, pasward@xxxxxxxx, "R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
there are a number of integrated versions where a hardware token has an "on-device" numeric keypad or even some sort of "on-device" biometric sensor like a fingerprint reader. that can slightly cut the total cost if there is always a one-to-one relationship between hardware token and secure reader ..... but in an environment where there is a large ratio of cards-to-readers ... then it is more expensive.

one of the issues is that the original target market for "smartcards" is now occupied by PDAs and cellphones (i.e. portable computing devices .... but with advances in technology so that the input/output is now integrated). reduced function chip-cards could be used as secure hardware tokens for authentication ... w/o carrying the overhead and costs of much of the current generation of smartcards ... i.e. the AADS chip strawman at:
https://www.garlic.com/~lynn/x959.html#aads

a secure PDA or cellphone should be a lot easier to do than getting a full-blown secure PC (where there could be an embedded chip that represents the secure hardware token functionality).

kentborg@xxxxxxxx on 11/26/2001 02:27 pm wrote:
Interesting.

Sounds like my suggestion of a mini combo IBM cryto card and a user authentication input device--but split in two, where the user has to trust the integrity of the keypad. But it would be a lot cheaper per consumer, which means it might actually happen.

-kb, the Kent who doesn't like logging into his basement server from a computer he doesn't physically control, such as those at an internet cafe.


Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"

Refed: **, - **, - **
From: Lynn Wheeler
Date: 11/26/2001 03:26 PM
To: <pasward@xxxxxxxx>
cc: dcsb@xxxxxxxx, Kent Borg <kentborg@xxxxxxxx>,
"R. A. Hettinga" <rah@xxxxxxxx>
Subject: Re: Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
my only claim is that it would be a whole lot easier to fix cell-phone software to make cell-phones secure (for some measure of security) ... than it would be to change all the PC software to make PCs secure (to the same measure of security). also, adding a separate hardware embedded chip that was specific for authentication wouldn't be difficult.

however, all security is relative .... frequently cost/benefit trade-off (aka translate "easier" in previous paragraph into "dollars" ... the cost difference between cellphones and PC is likely to be several orders of magnitude) .... also some from the security proportional to risk thread:
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe???

at 11/26/2001 3:10 PM wrote:
It is my understanding that the by-design security of various cellphones is such that they are relatively trivial to break into. There has been some discussion of this on comp.risks.


A PKI Question: PKCS11-> PKCS12

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/27/2001 05:45 PM
To: Hal Lockhart <hal.lockhart@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx, "'RAGHAVENDRAN H. (SSG) - CTD, Chennai.'"
    <raghavh@xxxxxxxx>
Subject: RE: A PKI Question: PKCS11-> PKCS12
PKI key operations can be put into two categories .... authentication (digital signatures) and secrecy/privacy (encryption).

It is reasonable to have a hardware token with a private key that was generated in the chip and never leaves the chip for use in authentication applications .... i.e. digital signatures for reliably authenticating an entity.

Most key escrow and business continuity issues involve privacy, secrecy, encryption and recovery of information; aka essential corporate assets protected with encryption could be lost if the access to the encryption key only existed in a single chip and that chip malfunctioned (a continuous availability issue with regard to no-single-point-of-failure and redundancy ... for high value assets, frequently not even simple duplicates, but even higher levels of redundancy and availability).

While it is possible that the same kind of chips and similar public key technology may be used in the two cases, the actual business processes (authentication and secrecy/privacy) have different requirements and design points.

It is possible to define chips/crypto for use in authentication-only business processes to have requirements that the private key be unique to a hardware token and never divulged. At the same time, it is also possible for essentially identical chips/crypto for use in secrecy/privacy business processes to have requirements that there be no single point of failure (even down to the hardware token containing a private key) which involving critical business assets. To meet business continuity and availability requirments it is possible that private keys involve in encryption for secrecy/privacy issues be replicated via means like key escrow.

The business requirments are different for the two different scenarios, even if the technology is otherwise identical.

on 11/27/2001 11:59 AM wrote:
Generating a secret on a smartcard and having it never leave the card is a major security feature to many people. For example, I believe it is mandated by Identrus for financial transactions. It is certainly a major motive for using smartcards, since it insures that all copies of the key are protected, not just one of them. It also insures that an attacker can not read out the key and use it in some environment where the card is not present.

On the other hand, many people believe in the benefits of key backup, particularly in a corporate environment, where the assets being protected belong to the organization not the individual. Also some folks believe that a central facility can do a better job of generating unguessable keys than a smartcard with limited processing power.

There is never any reason to protect certificates, since they are signed and intended to be public knowledge. They tend to take a lot of precious space on a smartcard. But, given the lack of a universally deployed directory infrastructure, it is convenient to have them "with you".

However, trusted root keys (which may be held in a self signed certificate for processing convenience) must be protected from modification.

Hal


A PKI Question: PKCS11-> PKCS12

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/27/2001 09:10 PM
To: Richard Culshaw <RCulshaw@xxxxxxxx.au>
cc: <ietf-pkix@xxxxxxxx>,
"'RAGHAVENDRAN H. (SSG) - CTD, Chennai.'" <raghavh@xxxxxxxx>
Subject: RE: A PKI Question: PKCS11-> PKCS12
note that bank vaults and armored trucks have things put into and taken out of them all the time ... and they are still considered secure.

in the scenario of digital signature & public key for authentication, it is possible that there is a business requirement for non-divulging/exporting the private key.

however, in the scenario of hardware tokens protecting private key(s) involved in secrecy/privacy encryption there can be significant reasons for having private key replication ... especially if very valuable corporate assets are involved.

hardware tokens can be secure .... whether they implement private key exporting or not. In the business process of authentication there can be higher confidence that with a non-export private key policy there is improved non-repudiation. However, that shouldn't negate the fact that similar secure hardware tokens can't be used to protect private keys that have been replicated for various business purposes (that don't involve things like non-repudiation).

There can be some confusion when identical technology is being used for totally different and distinct business purposes .... where the associated business requirements for the different business processes can place different requirements on the technology.

on 11/27/2001 4:27 PM wrote:
HI there,

I have tested numerous different smart cards/USB tokens and software combinations and have not seen one that offers a p12 export facility. The Purpose of having a smart card is to be able to securely store the Private key, if it can be exported from the smart card/token then it isn't really secure.

Richard Culshaw


A PKI Question: PKCS11-> PKCS12

From: Lynn Wheeler
Date: 11/28/2001 10:55 AM
To: Hal Lockhart <hal.lockhart@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx,
"'RAGHAVENDRAN H. (SSG) - CTD, Chennai.'" <raghavh@xxxxxxxx>
Subject: RE: A PKI Question: PKCS11-> PKCS12
the categories were respect to business processes and business requirements .... there has been recent thread in this mailing list somewhat touching on the fact that technology implementations and business requirements might not necessarily match up very well ... as well as some number of people working with PKI understanding that there are fundamentally different business processes and business requirements using the same technology.

Note that it is somewhat mute issue with regard to software PKI implementations .... the possible business requirements don't see a lot of differences until you get to hardware token and then there can be a real issue of whether or not the private key is ever divulged. Also from a business continuity stand-point .... there can be short-cuts in many of the secrecy protocols involving date-in-flight (including email) ... it is long-term encryption involving data-at-rest where non-replicated keys can become serious business risk (and single-points-of-failure). Nominally email is immediately decoded and possibly NACK'ed if there is a problem (like my private key is broken), aka email is much more of a data-in-flight business operation.

Not having replicated keys for protected, encrypted data-at-rest business assets is analogous to not taking backups and having business continuity plans. Several years ago, there was some study that of the businesses that didn't have disk backups of business data when there was hard disk failure ... half filed for bankruptcy within the first 30 days (after the disk failure). Loss of hardware-token/key for critical business assets protected by encryption ... effectively can represent equivalent loss of the data.

With regard to SLL merchant authentication with merchant server domain name certificates for SSL ... the CA signing serves most of the authentication function with the merchant key serving the encryption function (for key exchange) .... with somewhat the caveat that if the merchant can decrypt the key exchange it also has an implied authentication Any other activity with regard to merchant key is somewhat protocol chatter ... i.e.

1) if the merchant certificate validates (with the CA key) and the domain name matches there is first level of authentication (CA key is an authentication business process)

2) if the merchant can decrypt the key-exchange from the client (and correctly respond with encrypted message) .... then there is pretty good proof that the merchant is the corresponding entity from #1.(merchant key is a encryption business process).

at 11/28/2001 9:37 am wrote:
> PKI key operations can be put into two categories .... authentication
> (digital signatures) and secrecy/privacy (encryption).
I know this is the orthodox theory, but in practice IETF PKI protocols and applications make this difficult or impossible. Generally one key is used for Authentication and Key exchange, effectively encryption.

That's how TLS and IKE work. Just try using two keys with Outlook.

Hal


A PKI Question: PKCS11-> PKCS12

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 11/28/2001 02:35 PM
To: Eric Norman <ejnorman@xxxxxxxx>
cc: "Ietf-Pkix (E-mail)" <ietf-pkix@xxxxxxxx>,
"'RAGHAVENDRAN H. (SSG) - CTD, Chennai.'" <raghavh@xxxxxxxx>,
Richard Culshaw <RCulshaw@xxxxxxxx.au>
Subject: RE: A PKI Question: PKCS11-> PKCS12
try bank debit card infrastructure. there is a hardware token/box that is protecting the bank's "key" which then all of the individual account keys are encoded with. for a large bank, there could be dozens of these hardware units to handle the debit transaction load. In addition, there are copies of the keys likely escrowed in some other institution's safe deposit box (aka keeping the escrow in the same institution's safe deposit boxes could represent a collusion risk).

It is slightly analogous to a CA model (in that the bank's key is encoding the account key as opposed to signing the account key) ... except then all transactions are coming back to the account-authority (i.e. the account-authority and the relying party are the same), and the hardware box gets fed the encoded account information, the transaction ... and validates the transaction.

on 11/28/2001 11:19 AM wrote:
It seems to me that if a corporation has designed its business practices such that valuable corporate assets pass through a single point of encryption (aka single point of failure), then it would be wise for that corporation to review and adjust its business practices.

Eric Norman

"I may be just a butterfly, but watch out if I flap my wings"


CFP: PKI research workshop

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/26/2001 01:03 PM
To: Ray Dillinger <bear@xxxxxxxx>
cc: Carl Ellison <cme@xxxxxxxx>, cryptography@xxxxxxxx,
SPKI Mailing List <spki@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
note that the certificate-based PKI is an offline model .... it is the credit card model pre-1970. the certificate-based PKI tends to bear a lot of other resumblance to pre-1970 offline credit-card model .... the CRLs invention is very similar to the paper booklets that were mailed out to merchants every month of invalid credit card numbers (the credit-card industry however had a significant advantage having a very strong relying-party registration function .... so that there was high probability of relying-parties getting the paper booklets of invalid numbers).

in the '70s, the credit card industry switched from an offline infrastructures (aka similar to the certificate-based PKIs which were effectively developed to address the offline email infrastructure of the early 1980s) to an online infrastructure ... where every transaction was executed online. A certificate-based PKI for credit cards would be like regressing 30 years to the offline infrastructure (although using more convoluted and complex technology). The issue is why would the payment card industry want to regress 30 years to an offline model with certificate-based PKI?

The financial industry has passed an online payment definition that does use digital signature technology w/o all the complexity and short-comings of a certificate-based PKI (that would set-back/regress the infrastructure 30+ years to the offline model) .... which is X9.59.

Baiscally X9.59 defines a retail payment object that is valid for ALL electronic online financial transactions (internet, non-internet, point-of-sale, debit, credit, ACH, etc) which basically requires a digital signature and does not require a certificate-based PKI. The simplest analogy is that digital signature technology upgrades the PIN-based infrastructure found in current debit transactions and expands it to all electronic financial transactions.

There have been some financial pilots using certificate-based PKI operations .... but in all cases it is relatively trivial to show that the certificate is redundant, superfluous and extraneous in an online world. The certificates were effectively relying-party-only certificates (basically containing an account number and a public key) .... in part to meet liability and privacy requirements. Since only an account number was used and the transactions &/or other operations were all online ... they all referenced the account in order to execute the requested operation. It is trivial to show that given online operation executioin (including things like "logging in" for vaious kinds of things related to online banking and/or other financial or securities industry transactions) .... that is superfluous to have the certificate.

The certificate makes sense in an offline environment where there is no prior business relationship between the entities. Given online situations involving parties with prior relationships, certificates make no sense.

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

misc certificate-less digital signature references (including pointers to the NACHA/debit network implementation ... and a private key hardware token description allowing the same private/public key to be used in an arbritrary large number of different & public operations):
https://www.garlic.com/~lynn/x959.html#aads

random client digital signature authentication refs:
https://www.garlic.com/~lynn/subpubkey.html#radius

misc. discussion of certificate-based SSL domain name operation:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

ray dillinger on 12/26/2001 12:03 pm wrote:
Yep. So far, that's true. Financial stuff is the only killer app in sight for a PKI, and the financial services sector is conservative and heavily regulated. There is a substantial barrier to entry: just try to imagine running off a few thousand PKI-backed credit cards and going into business competing against mastercard/visa/amex. Vendor acceptance is slow and the regulatory hurdles are high.


........
Odds are, however, that each and every one of them is going to want their own PKI -- where P stands for Private, or Proprietary, rather than Public. A Public Key Infrastructure happens when the chaotic situation which that brings about gets consolidated and standardized, so don't look for that for at least a decade. Basically we have no chance of getting a Public Key Infrastructure in place right now because we don't have enough different Private Key Infrastructures in place for it to have started to hurt yet. People won't go for the PKI until they are in some kind of pain that it relieves. And if financial services businesses are involved, they will do it in such a way that no PKI vendor ever makes a profit they could possibly have made themselves. Look for them to be buying regulations that say PKI is part of financial services and can only be provided by licensed financial services corporations sometime in the next few years.

Like I said, don't get too discouraged -- these things happen slowly and it's very much a matter of stages of development. People don't do things until the pain of not doing them gets worse than the pain of doing them. Public Key comes about when Private Keys have been common for several years and their multiplicity causes pain. That in itself will take several years after the Private Key structures are fully adopted. The Private Key structures get adopted several years after the profit margins, split between consumers, vendors, and financial institutions, each overcome the pain of changing infrastructure. That will take several years after the initial offering. The initial offerings are happening now in very restricted markets, but don't look for it to happen in domestic consumer markets until the results of the restricted-market offerings are several years old and the technology involved hasn't changed AT ALL for several years. They are looking for a technology that's been in use long enough to establish a baseline and get results that look stable and repeatable. That's when financial services companies will begin to take them seriously enough to consider that the pain of deploying new infrastructure may overcome the painof absorbing losses due to fraud.

These are just network effects: PKI will trickle through at the end as surely as water runs downhill, because it's a better solution. It's just going to take a decade or two, or maybe four or five decades if there's a substantial monopoly somewhere in the industry.

Bear


CFP: PKI research workshop

From: Lynn Wheeler
Date: 12/26/2001 01:35 PM
To: Matt Crawford <crawdad@xxxxxxxx>
cc: cryptography@xxxxxxxx,
SPKI Mailing List <spki@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
possibly not the ATM you were thinking of .... certificate-less digital signature authentication by NACHA/ATM/debit networks
https://www.garlic.com/~lynn/x959.html#aads

specific web page:
https://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

financial industry standard for digital signature authenticated electronic payment transactions for all payments (x9.59):
https://www.garlic.com/~lynn/x959.html#x959

misc discussions regarding privacy and certificate-less digital signature authentication
https://www.garlic.com/~lynn/subpubkey.html#privacy

matt crawford on 12/26/2001 8:20 am wrote:
As I never tire of saying, "PKI is the ATM of security."

Meaning that has a certain niche relevance, but is claimed by proponents to be the answer to every need, and is the current magic word for shaking the money tree.


CFP: PKI research workshop

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/26/2001 02:36 PM
To: Ray Dillinger <bear@xxxxxxxx>
cc: Matt Crawford <crawdad@xxxxxxxx>, cryptography@xxxxxxxx,
SPKI Mailing List <spki@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
again, why would the financial industry be interested in regressing (at least) 30 years to a certificate-based offline model?

they do authentication of transactions that they also need to do authorization for .... in a model that has prior business relationship between the parties. certificate-based PKI were targeted at offline email genre of the early '80s and analogous to the offline credit-card model pre-70s.

in addition to the x9.59 for all electronic payment transactions ... it is possible to extend online authentication where the institution possibly isn't also responsible for the authorization (and/or access privileges).... things like FAST projects in FSTC:
http://www.fstc.org/projects/fastaggregation.cfm

ray dillinger on 12/26/2001 12:31 pm wrote:
In fact, that may be exactly it. PKI, as espoused by vendors, once established, will become an indispensable monopoly, like AT&T before the breakup. Investors love the fantasy of buying a kajillion shares for cheap today and then having them be shares in an indispensable monopoly next year, so they are inclined to believe.

The problem is that none of the vendors are offering anything that someone who has significant volume (like a financial-services company might) cannot provide for themselves. The FS companies can easily wait to adopt, because the margins offered by PKI are fairly small and the initial investment required is fairly large. Perhaps the margins will remain too small until royalty payments can be eliminated entirely (until any patents expire) and the FS companies can roll their own. Whether or not the margins are too small, The FS companies can wait that long easily.

But the PKI vendor cannot wait. S/he will be out of business in three or four years if nobody adopts. The patents will be for sale then much cheaper than the royalty payments s/he is offering, and the FS negotiator across the table knows it. The PKI vendor therefore is going to get the worst end of the deal every time s/he goes to financial services vendors, because s/he is not dealing from a position of strength, and had best learn the harsh lesson sooner rather than later.

A PKI will happen, eventually, but nobody is going to get into a position where the financial-services sector depends on them and has to pay them. That's as fundamental in business as the second law of thermodynamics in physics, and chasing the dream of becoming an indispensable monopoly to the financial services sector promises to be as frustrating to the seekers as the quest for a perpetual motion device.

Bear


CFP: PKI research workshop

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/26/2001 03:13 PM
To: cryptography@xxxxxxxx, SPKI Mailing List <spki@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
I doubt if fast/fstc participants would look at the following example as a prime example .... but there are various "age" authentication services that are available on the internet today ... basically associated with adult entertainment ... but would also be applicable to online gambling, various kinds of online purchases (alchohol), etc. It doesn't have to identify who you are ... it just has to be able to answer the question that you are at least of legal age.

now, it turns out that most of these services use effectively a "loop-hole" in the current online credit card system to implement their age authentication operation. There is such a thing in the industry called a "one dollar auth". Credit card operations typically have financial transactions authentication and authorized in real time .... but the actual request for funds transfer is typically submitted in batches ... at end of day or possibly end of shift. A "one dollar auth" is an authorization request for a one dollar credit card transaction, typically also with name & AVS (address verification) data. If the name, account number, and AVS all verify .... and there are no other outstanding problems .... then the request comes back approved. The "age" authentication services typically are registering individuals by requesting the information to perform a "one dollar auth" .... where there is no subsequent batch submission for actual funds tranfer. If the "one dollar auth" is approved, the age authentication services take the result as indication of legal age .... the credit card owner needing to have been of legal age to have legally signed the credit card contract and obtained the credit cad in the first place. Since no funds transfer actually takes place, nothing shows up on the consumer's credit card bill. The age verification service is charged a very nominal transaction fee for the "one dollar auth" (along with the AVS transaction).

The age verification service then just packages that one time charge into the fees that they charge their customers. They effectively maintain a local "cache" of the answer to the "one dollar auth" transaction.

I would contend that the evidence that such things are going on today ... is that the current system is "open" in the sense that it has open standards (like ISO 8583) and lots of entities are making use of it.

In theory, one opportunity for FAST-like offerings is for the financial industry to get directly into the age authentication service business (in theory being able to do it at least as well with the data as the 3rd party players out there today). A x9.59-like transaction can be defined .... but in place of "dollar amount", there are misc. other types of fields .... like "legal age". The consumer then digitally signs the transaction and forwards it to the merchant or server. The server takes the transactions and ejects it into the appropriate authentication network (very much like credit card transactions are done today) and gets back a "YES/NO" answerr (again very much like credit card transactions happen today) .... the only difference is instead of asking for consumer funds approval, the merchant is asking question about legal age. Identity information isn't being divulged ... not even date-of-birth ... which could raise a serious identity fraud question .... just answerring YES/NO to the legal age question. It could look like an X9.59 transaction, taste like an X9.59 transaction ... but instead of having funds involved, it has legal age involved.

It effectively creates an "open" online, authentication infrastructure ... requiring consumer to digital sign the transaction .... and a recognized certification authority providing real time, non-privacy invasive, answers. It otherwise has all the elements of an open public key infrastructure (registration authorities, certification authorities, consumers, relying parties, etc) w/o any certificates. In that sense it is an online PKI paradigm .... rather than the certificate-based offline PKI paradigm (which emulates the pre-70s offline credit card infrastructure).

at 12/26/2001 2:36 pm wrote:
in addition to the x9.59 for all electronic payment transactions ... it is possible to extend online authentication where the institution possibly isn't also responsible for the authorization (and/or access privileges).... things like FAST projects in FSTC:
http://www.fstc.org/projects/fastaggregation.cfm


CFP: PKI research workshop

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/26/2001 06:26 PM
To: "Perry E. Metzger" <perry@xxxxxxxx>
cc: cryptography@xxxxxxxx, "Phillip Hallam-Baker" <hallam@xxxxxxxx>,
"SPKI Mailing List" <spki@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
for the most part HTTPS SSL is certificate manufacturing (a term we coined a couple years ago) .... "infrastructure" typically implies the administrative and management .... which would require (at a minimum) CRLs for a certificate-based PKI.

the interesting thing about the use of SSL domain name server certificates is that they supposedly are addressing an integrity issue in the domain name infrastructure .... i.e. SSL checks that the domain name listed in the SSL domain name server certificate is the same as the domain name clicked/typed in for contacting the server. The issue is that the domain name could be hijacked and instead of going to the "real" IP-address .... it gets rerouted to a fraudulent IP-address.

however, if you track back the trust infrastructure for the SSL domain name server certificate .... the process is somebody applies for a SSL domain name server certifificate with a certification authority. The standard operating procedure for certification authorities is that they typically have to verify the information that they are certifying (in this case domain name ownership) with the authoritative agency for the information (in this case the domain name infrastructure). Now since there could be an integrity problem in the domain name infrastructure with respect to domain name hijacking ... there in fact could be a domain name hijacking prior to the application for a certificate .... which results in the issuing of a valid SSL domain name server certificate to the wrong entity.

One of the suggestions for addressing the domain name infrastructure integrity issue is for public keys to be registered at the same time as the domain name .... and then further communication with the domain name infrastructure be with digitally signed messages ... as part of the process for thwarting domain name hijacking. Note however, since the domain name infrastructure is the registration authority for the public key as well as the relying party receiving the signed messages .... certificates are redundant, superfluous, and extraneous .... even tho it still could be considered a (certificate-less) "publick key infrastructure" with significant administrative and management support.

The other interesting aspect is that the existing domain name infrastructure is set up for (presumably) trusted, (near) real-time distribution (and updating) of almost any kind of information; not just the (nearly) trusted binding of domain name to IP-address. Given that public keys are also registered with domain names at the same time as domain name and ip-address .... then a trusted domain name infrastructure could be relied upon to implement a (certificate-less) near real-time "public key infrastructure" (with full administrative and management functions already in existance) .... aka the domain name infrastructure could optionally distribute public key in the same response that it distributes ip-address ...... eliminating the requirement for a certificate-based PKI for trusted public key distribution.

This is somewhat a catch-22 .... that one of the solutions to addressing a basic SSL domain name certificate integrity problem (i.e. a CA has a broken trust chain if there is an integrity issue with the authoritative agency responsible for the information that a certification authority must certificate) could also be the solution eliminating any requirement for SSL domain name certificates.

As an aside, having the public key at the same time as the ip-address for setting up the base TCP session could also be used to simplify the normal SSL session setup (since there is no certificate distribution that has to occur).

random additional discussion:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

there is also the claim that 99.99999 percent of client authentication in the internet world today is radius-based; typically userid/password (although radius supports multiple authentication processes specifiable at an individual userid/account level). There has been work done on an authentication process for radius involving digital signature where a public key is registered in place of a password. This would also represent a (certificate-less) public key infrastructure with full administrative and management support.

random radius discussion
https://www.garlic.com/~lynn/subpubkey.html#radius

for pointer to radius standards & documents:
https://www.garlic.com/~lynn/rfcietff.htm

& click on Term (term->RFC#)

and then click on "RADIUS" in the Acronym fastpath section
remote authentication dial in user service (RADIUS )
see also authentication , network access server , network services
3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058


also of some interest are the AAA rfcs:
Authentication, Authorization and Accounting
see also accounting , authentication , authorization
3127 2989 2977 2906 2905 2904 2903


perry e. metzger on 12/26/2001 3:45 pm wrote:
HTTPS SSL does not use PKI. SSL at best has this weird system in which Verisign has somehow managed to charge web sites a toll for the use of SSL even though for the most part the certificates assure the users of nothing whatsoever. (If you don't believe me about the assurance levels, read a Verisign cert practice statement sometime.)

Of course, client side certificates barely even exist, although people made substantial preparation for them early on in the history of all of this.

Were it not for historical accident no one would care about "PKI" in this context.

> S/MIME use is significant and growing.

I get PGP encrypted mail a few times a week. I've never received a request from any counterparty to set myself up to receive S/MIME. Your mileage may vary.

> The financial industry is not looking at offline PKI models in
> general.

When I was still doing security consulting, nearly every firm I worked for had installed Entrust or something similar -- and none of them used the systems for anything.

PKI and the Emperor's New Clothes have a bunch in common.

> As for what PKI vendors have been up to, the sucessful ones have been
> supporting private label certification hierarchies from the start.

The PKI vendors are, I think, largely surprised by what has happened. They were expecting things like lots of mutual authentication using PKI to be in place, and in fact, there's almost none in use at all.

I think many of the PKI vendors haven't been doing too well -- some of them that I used to have dealings with barely exist any longer. The one business that seems to make money is charging a toll for running an e-commerce site. I wonder who they might be.

Of course, none of this should be surprising in the least. Commerce and the PKI model have nearly nothing to do with each other. Some of us were writing about this years ago.

Perry E. Metzger perry@xxxxxxxx


CFP: PKI research workshop

From: Lynn Wheeler
Date: 12/27/2001 08:22 AM
To: Ben Laurie <ben@xxxxxxxx>
cc: cryptography@xxxxxxxx, Nelson Minar <nelson@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
it isn't that you move it to a central authority .... you move it to an authority that typically is already established in association with authorization ... aka in normal business operation, a business relationship is established that typically consists of creating an account record that has various privileges associated with that account/entity. For authentication purposes a public key can be bound to that account and/or set of privileges. This goes on in the world today .... and would continue to regardless of whether x.509 identity certificates were issued or not. given that businesses have to play the registration function for authorization & privileges ... aka normal procedure doesn't allow somebody to walk into a random bank and withdraw funds from a random account ... regardless of who they are ... aka identity doesn't magically enable a person to withdraw funds from an arbritrary account ... ability to withdraw funds typically is a privilege associated with whether or not some entity is authorized to perform that function for a specific account. As such, the financial institution has to register lots of information for the account ... also registering a public key is consistent with the existing business processes, liability, administrative and management infrastructure.

In effect, large numbers of business processes already exist for registration, administration, and management of authentication information .... and having a certificate in the loop doesn't eliminate those business processes (whether or not I had a certificate .... there still would have to be something registered that some attribute of "me" has authorization to do certain things). Doing business flow and informatioin management optimization just demonstrates that given existing business infrastructures for registration, administration and management which also includes certificates it is usually trivially possible to demonstrate that the actual certificates are redundant, superfluous and extraneous ... aka directly registering the public key and providing direct binding between the authentication process and the authorization process .... eliminating a possibly huge number of extraneous and unnecessary business entities and business processes associated with certificate-based operation.

There doesn't have to be any single central authority in a certificate-less model. There can be all sorts of authorities for all sorts of infomation .... which could be also hypothesized for a certificate-based certification and authentication model. However, the certificate-less exercise typically trivially demonstrates that any certificate-based solution duplicates existing business processes which aren't going to be eliminated. Therefor, it is then possible to demonstrate business optimization where the duplicate (certificate) business processes can be eliminated as extraneous, redundant, and superfluous.

on 12/27/2001 7:16 am wrote:
As for the certificate-less model - all this really does is move the binding from something you can carry around with you to something that has to be done by a central authority. It is not clear to me why this is such a marvellous improvement. Unless you happen to want to own the central authority, of course, which, unlike certificates and CAs, is far harder to replicate privately and therefore, presumably, potentially even more profitable than Verisign's cash cow.

Cheers,

Ben.


CFP: PKI research workshop

From: Lynn Wheeler
Date: 12/27/2001 04:08 PM
To: pgut001@xxxxxxxx (Peter Gutmann)
cc: crawdad@xxxxxxxx, cryptography@xxxxxxxx, spki@xxxxxxxx
Subject: Re: CFP: PKI research workshop
I would tend to make the statement even stronger.

large, complex legacy systems tend to have slow technology uptake. most of the certification authorities can be deployed in simple demos w/o impacting the legacy systems and business process (possibly as a front-end process that is pealed off before turning things over to the legacy business process).

if you have legacy business process designed to support millions or hundreds of millions of customers ... then any change to that system tends to be significantly more expensive than a stand-alone certification authority demo for a couple hundred. The problem has been the cross over from toy-demo to real production. In general, the legacy infrastructures and business processes have been put into place for perfectly valid reasons .... even if somewhat slow to change.

I'm acquanted with one example where a single screen update (as part of a new function rollout) to a customer call-center supporting tens of million customer environment cost more than a dozen or so certification authority demo systems. The issue was that call center was highly optimized and had significant investment to scale into handling tens of millions of customers very, very efficiently. To optimize a single screen & get it integrated into a real live production environment required some amount of investment. Such things as customer call-centers (not to mention scalable customer call centers, scalable administrative and management infrastructure, etc) for a customer service oriented operation .... could be totally ignored when testing purely demo operations.

However, even with the cost of modifying a legacy operation .... where authentication is integrated into the standard every day business processes .... is significantly cheaper than trying to treat authentication as an independent service (and build a separate scalable infrastructure that real customer service orientation involves).

As an aside point ... I've found very few business operations that go around trying to perform authentication operations purely for the sake and enjoyment of performing authentication operations. For the most part, businesses will perform authentication operations (typically viewed as overhead or cost issue) as part of some real, productive business service (a revenue issue). I find it difficult to come up with a whole lot of scenarios where cost overhead (authentication) operations are performed for no business (revenue) purpose. As mentioned in prior posting
https://www.garlic.com/~lynn/aadsm9.htm#cfppki6

given that authentication is being performed as part of some business process or function ... then it is normally trivial to show it is easier to have authentication (even digital signature authentication) integrated into such business processes .... and correspondingly easy to show that certificate-based operations are redundant, superfluous and extraneous (modulo the issue of toy demos are cheaper than modifying production business operations).

pgut001@xxxxxxxx on 12/28/2001 3:41 am wrote:
Naah, it's the monorail/videophone/SST of security. Looks great at the World Fair, but a bit difficult to turn into a reality outside the fairgrounds.

Peter (who would like to say that observation was original, but it was actually stolen from Scott Guthery).


CFP: PKI research workshop

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/28/2001 04:50 PM
To: Ray Dillinger <bear@xxxxxxxx>
cc: crawdad@xxxxxxxx, cryptography@xxxxxxxx,
Peter Gutmann <pgut001@xxxxxxxx>, spki@xxxxxxxx
Subject: Re: CFP: PKI research workshop
both atm debit network and domain name infrastructure care capable of local caching .... so that timelyness is within seconds to minutes (or a few hrs as parameter within the needs of the infrastructure). the offline world for certificates is the analogy of the letters of credit from the days of the sailing ships. near real time with managed caching (with relying parties forced to deal with stale credentials manufactured months or years in the past).

part of the issue in clearing is who has the "liability" at any particular instance; in the case of debit network caching there are very specific procedures and processes. Are you suggesting that the certification industry will assume liability in the case of offline clearing associated with mars colonilization?

the process tends to be authentication, authorization, and finally settlement and clearing. sometimes authorization, settlement and clearing can be batched. if you are really talking about the bank account balance resides on the earth and the access is from mars .... offline authentication (clearing really needs to know whether the money actually exists or not .... regardless of whether or not you are dealing with the owner of the account) doesn't get you clearing .... and real clearing needs to know that the money really exists (not just that a person is authenticated) ... and if the account balance is on earth and it takes 30 minutes elapsed time to establish it ... then that it what it takes.

More realistic is account balance caching at some near real-time location on mars ... say within the parameters of the ATM withdrawal limit.

At one point in the PKI evolution there was the proposal that there could be certificates analogous to the '70s "signing limit" checks .,... an attempt to create certificates that not only provided authentication information but also some hypothetical useful approximation to authorization information (aka not quite reqressing totally to the pre-70s credit card model). The issue in the "signing limit" checks was when they found people writing 200 $5000 (limit) checks to get a million. What has been seen since that time is near real-time purchasing department operation (including business purchase cards that leverage the credit card system) to provide real-time aggregation ... as opposed to sinlge event operation. In the ATM machine withdrawal case, there are typically both single widthrawal limits as well as daily aggregate withdrawal limits (aka the PKI proposal for credit cards turned out to be a business process regression to pre-70s and the PKI proposal for business checks turned out to be a business process reqression to pre'80s).

Typically what you might have in a ATM withdrawal case .... with foreign ATM machine (not your local bank) .... is that the owner of the ATM machine is given a guarantee of funds from your financial institution prior to the ATM machine releases paper money. Your bank then effectively debits your account for the equivalent amount of funds. Then typically sometime that evening, there is a settlement operation where there is funds transfer from your bank to the financial institution that owns the ATM.

An offline, stale certificate .... only (slightly) addresses the issue of authentication .... say an identification certificate ... which might not even provide a binding between you and any particular bank or bank account. Some sort of binding between you, your bank, and your bank account is needed .... just for the authentication phase of what you are talking about. There is still the authorization phase needed so that the owner of the ATM machine believes that it can receive something (in return for spitting out paper bills). That effectively has to find that there are actually sufficient funds in your account.

So a more realistic scenario would be that there is possibly dual account, one local and one on earth ... with funds floating back and forth as needed in evening settlements. If you are on Mars there is some local financial branch with local record of funds that you have immediately available and which can authorize that amount of money.

A "local" financial branch implementation and a digital cash implementation might have a number of similar useability attributes .... aka from the standpoint of how local funds do you have immediately available .... aka funds are transferred into you local PDA as digital cash for immediate use .... or funds are transferred into the local financial institution for immediate use.

ray dillinger on 12/28/2001 2:29 pm wrote:
The only case in which the PKI solution is not redundant is in offline clearing. But getting your point-of-transaction online is easier than paying attention to PKI.

I happen to like offline clearing -- it opens up the possibility of new transaction types and doing transactions in places you couldn't before. But the practical issue is, everybody who's interested in electronic transactions of any kind is also interested in getting online, and when PKI's were deployed in "developing" areas (south africa) they got dumped just as soon as the area was developed enough for communications to support online clearing.

On the principle of people refusing to adopt something until it relieves pain, maybe we won't see a real PKI deployed until we need to serve markets where speed-of-light delays make online clearing impractical.

Mars, for example, is 3 to 22 light-minutes away. I don't imagine someone using an ATM on Mars is going to want to wait 12 to 88 minutes for online clearing (more if the protocol is talky or the bandwidth is busy...). So a martian colony might be the first practical application of PKI and/or digital cash, assuming the colonists want to do business with Earth companies. But a colony looks pretty distant right now: we haven't even got an outpost there yet.

Bear


CFP: PKI research workshop

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/29/2001 03:22 PM
To: Andrew Odlyzko <odlyzko@xxxxxxxx>
cc: cryptography@xxxxxxxx
Subject: Re: CFP: PKI research workshop
everyday life has a lot of cryptography ... for instance ... there is quite a bit of cryptography involved in every debit transaction (every time you get money from ATM machine or use point-of-sale terminal).

a lot of PKI revolves around the business process of strong authentication .... where some aspects of cryptography happens to be used. A subset of this saw extremely rapid uptake with regard to SSL and online shopping (again quite a bit of cryptography in use, one might make a case that cryptography should be like electronic dsitributors, everybody may have one ... but very few could actually build one from scratch or even know thay actually have one). One might be tempted to make the observation that uptake rate is much faster if it is filling a new need as opposed to trying to change existing operation.

However, PKI industry seems to have tried to make public key cryptography and certificates an "end in themselves". First off, certificates are a solution to strong authentication in an offline environment (aka early '80s offline email paradigm) which doesn't have a very good match to most of the business processes that are in use today.

A PIN debit transaction involves the relying-party (the consumer's bank both authenticating and authorizing the transaction .... authentication based on something you have and something you know ... and authorization on a combination of authentication, available funds, any previous transactions today, the aggregate value of any current day transactions, etc). Digital signature can improve the integrity of the existing PIN-debit based operation and also expand the use to open/insecure network (i.e. the existing PIN-debit is predicated on closed, secure network). This is what NACHA (national cllearing house association ... aka typically regional and national financial industry organizations that provide infrastructure for bank-to-bank wholesale financial transfers) did in the debit demonstration .... basically upgrading PIN-based cyrptography for authentication to digital-signature cryptography for authentication (where a shared-secret paradigm ... aka PIN-base was replaced with a non-shared-secret paradigm).
https://www.garlic.com/~lynn/x959.html#aads

There was no certificate necessary ... and, in fact, certificates aren't really about cryptography, there are more about a specific kind of offline business process (which is having difficulty finding a niche in an increasingly online world).

Furthermore, not only is the offline-paradigm certificate model having a difficulty finding a niche in an online world ... the idea of a purely authentication business process is possibly having trouble finding its niche ... referencing prior posting that most business tend to perform authentication ... a cost overhead ... as part of some useful, productive business process (not purely an end in itself)
https://www.garlic.com/~lynn/aadsm9.htm#cfppki7

One might envision a Monty Python Department of Authentication. Citizens are asked to visit their local Department of Authentication every day, state their name, and provide certificate/credential for proof of their claimed identity. The Department of Authentication doesn't actually record that they've prooved any identity and citizens aren't actually mandated to show up. However, if the citizens do show up everyday to their local Department of Authentication, it makes the DoA employees feel that they are providing a useful service in the scheme of the universe (as well as certificates/credentials that are voluntarily verified everyday are better than ones that aren't ... something like pet rocks).

Now, an interesting thing might be regarding rapid uptake of general security. One could contend that majority of the market believes that good, strong security should be an attribute of the basic infrastructure ... somewhat like the issue of automobile quality in the '70s, not going to pay any more for it ... but would migrate to a manufactur that had significantly better quality. You then have the 1) vendors that don't see quality as worth while since they won't be able to charge more 2) new vendors that would like to sell "quality" as a stand-alone attribute ... not actually having to manufactur automobiles .... but somehow convince customers that they can sell quality independent of any product, and 3) vendors that feel that they can eventually gain market share by providing better quality.

Substitute "security" and/or "PKI" in place of "quality".

Part of the issue is that security (and strong authentication) should be an attribute of the basic infrastructure ... not something that exists by itself in a vacuum.

odlyzko@xxxxxxxx on 12/28/2001 6:54 wrote:
Several of the comments about the slow uptake of PKI touch on what seem to be two basic factors that are responsible for this phenomenon:

1. Cryptography does not fit human life styles easily. As an example, truly secure systems would stop secretaries from forging their boss's signatures, and this would bring all large beaucratic organizations to a standstill.

2. Novel technologies take a long time to diffuse through society. "Internet time" is a myth. As just one example, a news story I just read was about the great success of online bill paying. This is all very well and good, but weren't we supposed to have that a long time ago? As a matter of fact, didn't Microsoft try to buy up Intuit back in 1994 largely in order not to be deprived of the possibility of controlling online payments? (I have two papers on this subject, one a short one, "The myth of Internet time" that appeared in the April 2001 issue of Technology Review, and a longer, more detailed one, "The slow evolution of electronic publishing," published in 1997, that argue that consumer adoption rates are not noticeably faster now than in the pre-Internet days. Both are available on my home page.)

Andrew Odlyzko


CFP: PKI research workshop

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/30/2001 04:42 PM
To: cryptography@xxxxxxxx
Subject: Re: CFP: PKI research workshop
another aspect that overlaps PKIs and quality is the difference between "application" code and "service" code .... turning an application into a service can be hard .... possibly writing 4-10 times as much code as in the base application infrastructure .... and very high-quality code .... dealing with potentially very complex failure modes. Related thread (buffer overflow) has been running in the sci.crypt newsgroups. .... partial reference:
https://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
https://www.garlic.com/~lynn/2001n.html#90 Buffer overflow

also an older thread regarding "assurance" in application and digital signature authentication
https://www.garlic.com/~lynn/aadsm5.htm#asrn1 Assurance, e-commerce, and some x9.59
https://www.garlic.com/~lynn/aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59
https://www.garlic.com/~lynn/aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59
https://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, x9.59, etc

lynn.wheeler@xxxxxxxx at 12?29/2001 3:22 pm wrote:
Now, an interesting thing might be regarding rapid uptake of general security. One could contend that majority of the market believes that good, strong security should be an attribute of the basic infrastructure ... somewhat like the issue of automobile quality in the '70s, not going to pay any more for it ... but would migrate to a manufactur that had significantly better quality. You then have the 1) vendors that don't see quality as worth while since they won't be able to charge more 2) new vendors that would like to sell "quality" as a stand-alone attribute ... not actually having to manufactur automobiles .... but somehow convince customers that they can sell quality independent of any product, and 3) vendors that feel that they can eventually gain market share by providing better quality.

Substitute "security" and/or "PKI" in place of "quality".

Part of the issue is that security (and strong authentication) should be an attribute of the basic infrastructure ... not something that exists by itself in a vacuum.


CFP: PKI research workshop

Refed: **, - **, - **
From: Lynn Wheeler
Date: 12/30/2001 05:01 PM
To: Ray Dillinger <bear@xxxxxxxx>, crawdad@xxxxxxxx,
cryptography@xxxxxxxx, Peter Gutmann <pgut001@xxxxxxxx>,
    spki@xxxxxxxx
Subject: Re: CFP: PKI research workshop
somewhat as an aside .... the "gift" cards (and other flavors) that you see at large percentage of retail check-out counters in the US are effectively digital cash ... although the current incarnation results in a different card at every retailer. however, they are online, magstripe-based digital cash .... utilizing the same ubquituous point-of-sale infrastructure as debit & credit (it is just that the transaction routing goes to different online transaction processing than credit & debit). The issue of whether or not it would be possible to use any card at any merchant is more of a business rule issue than a technology issue.

note from a higher assurance standpoint ... the x9.59 work is applicable to all electronic transactions .... whether they are credit, debit, e-check, OR (online) digital cash ... AND x9.59 transactions could flow over both existing ubiquituous point-of-sale network and/or a ubiquituous internet network (or any other kind of network).

random refs:
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/x959.html#aads

lynn.wheeler@xxxxxxxx on 12/28/2001 4:50 pm wrote:
A "local" financial branch implementation and a digital cash implementation might have a number of similar useability attributes .... aka from the standpoint of how local funds do you have immediately available .... aka funds are transferred into you local PDA as digital cash for immediate use .... or funds are transferred into the local financial institution for immediate use.


CFP: PKI research workshop

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/30/2001 05:45 PM
To: pgut001@xxxxxxxx (Peter Gutmann)
cc: bear@xxxxxxxx, pgut001@xxxxxxxx, spki@xxxxxxxx
Subject: Re: CFP: PKI research workshop
all the stored value digital cash systems that i've looked at .... whether "online" or "offline" ... with the cash deposited in offline chips .... has the same "issuer" skewed characteristic (aka whether the digital cash is in the chip or the digital cash is online someplace .... the issuer benefit is nearly identical).

my wife and I were asked to do pass/swag at the development on some of the offline digital cash operations (and had to do the end-to-end business analysis) and the issuer benefits were nearly identical to the online versions.

there everntually were words out of basil and some of the eu central banks .... that they would tolerant the benefit while such infrastructures were trying to achieve production operations .... but at some point successful operations would be asked to "share(?)" or split the benefit with the end consumer.

pgut001@xxxxxxxx at 12/31/2001 5:25 am wrote:
Uhh, no, they're several steps removed from a cash-equivalent, with things heavily skewed in favour of the issuers. See the slashdot thread about this at
http://slashdot.org/article.pl?sid=01/12/29/1414258&mode=thread
for a technical and legal analysis (yes, it is slashdot that has this, just make sure you set your noise threshold to 1 or 2).

Peter.


Small/Secure Payment Business Models

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 12/31/2001 01:29 PM
To: Ronald Duncan <Ronald.Duncan@xxxxxxxx>
cc: ietf-trade@xxxxxxxx, Ronald Duncan <Ronald.Duncan@xxxxxxxx>,
    'Steve Schear' <schear@xxxxxxxx>
Subject: Re: Small/Secure Payment Business Models
note that current gift & stored value cards found in large percentage of the larger retail store check-out counters ... provide a very inexpensive & successful "online" small payment model. They currently use magstripe cards and operate within the same point-of-sale infrastructure as debit & credit.

From a "secure" stand-point with respect to insecure networks ... they suffer the current downside as debit on the internet. However, x9.59
https://www.garlic.com/~lynn/x959.html#x959

is designed to provide strong authentication for all electronic payments (not just credit, debit, or e-echeck but ALL) in all environments (point-of-sale, internet, non-internet, etc).

NACHA has already tested an "internet" secure atm/debit with the aads/x9.59 model
https://www.garlic.com/~lynn/x959.html#aads

x9.59 is applicable to all the existing point-of-sale online electronic payment infrastructures and provides the necessary security for their operation over the internet .... aka X9.59 can be extended to not only secure credit and secure debit .... but the very same infrastructure can be extended to secure "stored-value" for small payments (aka there are existing business process infrastructures that already handle electronic small payments relatively efficiently .... the issue is the ability to use the same X9.59 that is design to secure all electronic payments .... to provide the additional security necessary for operation over untrusted networks).

some related discussions in crypto mailing list:
https://www.garlic.com/~lynn/aadsm9.htm#cfppki11
https://www.garlic.com/~lynn/aadsm9.htm#cfppki12


AADS Postings and Posting Index,
next, previous - home