Re: invoicing with PKI

2003-09-03 Thread James A. Donald
--
On 1 Sep 2003 at 12:23, Ian Grigg wrote:
 I suspect the widest use of public key crypto in a non-PKI
 context would be SSH, which opportunistically generates keys
 rather than invite the user to fund a PKI.  According to this
 page [1], there may or may not be 2,400k SSH servers

This of course enormously dwarfs the use of PKI certificates. 
Why?  Because an SSH server uses its public key to prove
continuity of identity, rather than true names, and this is lot
easier than true names.

Outlook and outlook express support digital signing and 
encryption -- but one must first get a certificate.

So I go to Thawte to get my free certificate, and find that 
Thawte is making an alarmingly great effort to link 
certificates with true name information, and with the beast 
number that your government has assigned to you, which imposes 
large costs both on Thawte, and on the person seeking the 
certificate, and also has the highly undesirable effect that 
using these certificates causes major loss of privacy, by 
enabling true name and beast number contact tracing of people 
using encryption.

Now what I want is a certificate that merely asserts that the 
holder of the certificate can receive email at such and such an 
address, and that only one such certificate has been issued for 
that address.  Such a certification system has very low costs 
for issuer and recipient, and because it is a nym certificate, 
no loss of privacy.

Is there any web page set up to automatically issue such 
certificates?

The certs that IE and outlook express accept oddly do not seem 
to have any provision for defining what the certificate 
certifies.

This seems a curious and drastic omission from a certificate 
format.

Since there is no provision to define what a certificate 
certifies, one could argue that any certification authority 
that certifies anything other than a true name connected to a 
state issued id number, the number of the beast, is guilty of 
fraud.  This would seem to disturbingly limit the usefulness 
and application of such certificates.  It also, as anyone who 
tries to get a free certificate from Thawte will discover, 
makes it difficult, expensive, and inconvenient to get 
certificates.


--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 id/UsYl2xTf9Mswn+zhPXu3gZK4Hx7RMoDuc1LXZ
 4TEx1/ENp2au248aS2r/SqmAc7NKT8yzMwGTk3dOK


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: invoicing with PKI

2003-09-03 Thread James A. Donald
--
On 1 Sep 2003 at 19:17, Hadmut Danisch wrote:
 Is cryptography where security took the wrong branch?

True names is where security took the wrong branch.  The entire
PKI structure has been rejected.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 23+XuDK7JTGYW75W2R6MyD+V56OpgktSnYqZ4GBT
 4OFVh0w6Cykrd+ETKSZ7D+1zB0+KUqjBmSgIFnmsG


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: invoicing with PKI

2003-09-03 Thread Ian Grigg
Peter Gutmann wrote:
 
 Hadmut Danisch [EMAIL PROTECTED] writes:
 
 There was an interesting speech held on the Usenix conference by Eric
 Rescorla (http://www.rtfm.com/TooSecure-usenix.pdf, unfortunately I did not
 have the time to visit the conference) about cryptographic (real world)
 protocols and why they failed to improve security.
 
 It was definitely a must hear talk.  If you haven't at least read the slides
 (were the invited talks recorded this year?  Any MPEGs available?), do so now.
 I'll wait here.

I read them twice the other say.  Recordings
would be nice.

 [Pause]
 
 The main point he made was that designers are resorting to fixing mostly
 irrelevant theoretical problems in protocols because they've run out of other
 things to do, while ignoring addressing how to make the stuff they're building
 usable, or do what customers want.  My favourite example of this (coming from
 the PKI world, not in the talk) is an RFC on adding animations and theme music
 to certificates, because that's obviously what's holding PKI deployment back.

:-) Was this an April 1st RFC?  Or a stealth DRM
effort?

 From the logfiles I've visited I'd estimate that more than 97% of SMTP relays
 do not use TLS at all, not even the oportunistic mode without PKI.
 
 I did a talk last year at Usenix Security where I said that all SSL really
 needed was anon-DH, because in most deployments that's how certificates are
 being used (self-signed, expired, snake-oil CAs, even Verisign's handed-out-
 like-confetti certs).

It's worth looking at these figures from 1st Sep 2003:

  Description  Count

  Valid35709
  Self Signed  9769
  Unknown Signer   27507
  Cert-Host Mismatch   40276
  Expired  54578

http://www.securityspace.com/s_survey/sdata/200308/certca.html

I used the total in my calculation to get 1.24% server
penetration, but the true story is way worse - only a
quarter are supposed PKI-valid.  The rest are deviant
in some form.

 It's no less secure than what's being done now, and
 since you can make it completely invisible to the user at least it'll get
 used.  If all new MTA releases automatically generated a self-signed cert and
 enabled STARTTLS, we'd see opportunistic email encryption adopted at a rate
 that tracks MTA software upgrades.

I've thought about this a lot, and I've come to the
conclusion that trying to bootstrap using ADH is not
worth the effort.  I think the best thing is if the
web servers were to automatically generate self-signed
certs on install, and present them by default.

Then, at least, we offer the opportunity for browsers
to do SSH-style time-trust analysis.

The forces of crypto-conservatism are so strong that
I suspect we only get one shot at saving the HTTPS
protocol.  Trying to get browsers and servers to agree
to like ADH seems too much a challenge.  Using self-
signed certs seems to promise more bang for buck.

For new applications, using ADH is definately a good
way to go.

iang

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: invoicing with PKI

2003-09-03 Thread Peter Gutmann
Peter Gutmann wrote:
It's no less secure than what's being done now, and
since you can make it completely invisible to the user at least it'll get
used.  If all new MTA releases automatically generated a self-signed cert and
enabled STARTTLS, we'd see opportunistic email encryption adopted at a rate
that tracks MTA software upgrades.

I've thought about this a lot, and I've come to the conclusion that trying to
bootstrap using ADH is not worth the effort.  I think the best thing is if
the web servers were to automatically generate self-signed certs on install,
and present them by default.

Right, that's what I meant - RSA is being used as anon-DH anyway, so we may as
well stop pretending and just make it fully automated and transparent to the
user.  If people do want to go to the effort of checking that everything is
OK, do it by checking the cert fingerprint in the same way that PGP and SSH
have been doing for years.

The main point he made was that designers are resorting to fixing mostly
irrelevant theoretical problems in protocols because they've run out of other
things to do, while ignoring addressing how to make the stuff they're building
usable, or do what customers want.  My favourite example of this (coming from
the PKI world, not in the talk) is an RFC on adding animations and theme music
to certificates, because that's obviously what's holding PKI deployment back.

:-) Was this an April 1st RFC?  Or a stealth DRM effort?

It's a real RFC (currently still a draft), Logotypes in X.509 certificates.
I originally suggested this as a joke a couple of years ago (Can you imagine
KPMGCoopersPriceLybrandWaterhouseAnderson distributing a single cert without
the Official Corporate Logo(tm) with Official Corporate Animation(tm) and
Official Corporate Song(tm) playing in the background?).  Given PKIX's
propensity for standardising anything that comes along (PKIX was formed to do
one thing and has become a standing committee that will do anything, provided
it is in ASN.1 syntax - Phil Hallam-Baker), it was only a matter of time
before a draft appeared.  I made the following suggestion for a further
addition to the RFC, but it hasn't been adopted (yet):

-- Snip --

4.3. Scent logotypes

Alongside audio and video logotypes, it may be desirable for certificates to
carry scent logotypes in order to uniquely brand certificate holders in a
manner meaningful to relying parties.  For example, McDonalds may choose to
imbue their certificates with the aroma of fried beef patties and grilled
cheese, the National Park Service may choose the essence of pure Colorado
mountain air with just a hint of pine, the NRA would use a heady mixture of
cordite and gun oil, and PKIX could use cold coffee and stale cigarette smoke.

The new logotype would be implemented in the form of scratch-n-sniff
certificates, and will assist relying parties in making informed decisions as
to whether a particular certificate is trustworthy and relevant for its
intended usage.  Service providers and product vendors invest a lot of money
and resources into creating a strong relation between positive user
experiences and easily recognizable scents such as grilled beef, fresh air,
and cordite, allowing easy and familiar branding of certificates.

The scent logotype extension MUST have the following syntax:

  LogotypeScent ::= SEQUENCE {
 scentSubtype IA5String, -- MIME scent subtype
 scentOCTET STRING,
 refreshInfo  ScentRefreshInfo OPTIONAL
 }

A MIME type is used to specify the format of the file containing the scent
logotype data.  The scent element contains the scratch-n-sniff scent logotype
associated with the certificate.

Since scents fade over time, it may be necessary to periodically refresh the
scent to preserve the user experience:

  ScentRefreshInfo ::= SEQUENCE {
 refreshTime  INTEGER DEFAULT 30,
 refreshCount [0] INTEGER DEFAULT 1,
 refreshUrl   IA5String,
 refreshUrlHash   OCTET STRING OPTIONAL }

The refresh time specifies the time in seconds after which the scent must be
refreshed, the refresh count specifies the number of times the scent should be
refreshed after initial deployment, and the URL and optional hash of the data
stored at the URL location contains the scent payload and integrity protection
mechanism.

7.1. Security considerations

Implementors should be aware that there exists the potential for confusion
among relying parties when evaluating similar scent logotypes.  For example,
relying parties may not be able to meaningfully differentiate between the
logos for McDonalds and Burger King, or Hersheys and Nestle, or Sealord and
Penthouse.  Resolution of this issue lies outside the scope of this memo.

Intensive usage of scent logotypes may trigger smoke alarms and, by extension,
sprinkler systems.  Users should be aware of this and carry an umbrella.

Certificate users involved in skunkworks projects are discouraged from 

Re: invoicing with PKI

2003-09-03 Thread Anne Lynn Wheeler
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:
http://www.garlic.com/~lynn/2003l.html#33 RSA vs AES
and slightly related post (also from sci.crypt):
http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model
--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: invoicing with PKI

2003-09-02 Thread Ian Grigg
(Things seem quiet on the crypto front, here's a late reply.)

Hadmut Danisch wrote:
 
 Hi,
 
 On Thu, Jul 17, 2003 at 04:27:52PM -0400, Ian Grigg wrote:
  Does anyone know any instances of invoicing and
  contracting systems that use PKI and digital orders?
 
  That is, purchasing departments and selling departments
  communicating with digitally signed contracts, purchase
  orders, delivery confirmations and so forth.
 
  And, the normal skeptical followup question, do they
  work, in the sense of delivering ROI, or are they just
  hopeful trials?
 
 
 Beyond invoicing/contracting, which applications of PKI
 in e-business or related areas are there anyway?

The dream of PKI seems to revolve around these major areas:

  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)

In terms of actual deployed PKIs, the only significant
cases that I know of, deployed outside of organisations
and in widespread use are:

   HTTPS (141k, see below), and
   OpenPGP (millions says PGP Inc, so let's call it 100k or so).

I suspect the widest use of public key crypto in a
non-PKI context would be SSH, which opportunistically
generates keys rather than invite the user to fund
a PKI.  According to this page [1], there may or may
not be 2,400k SSH servers, but it's unclear whether
that is the sample size or the sites found.

 (except
 for the standard tools SSL, X.509,...)

(Right, tools, not applications.)

 Is there a survey of where in e-business cryptography
 is actually being used between customers and providers?

There are specific things like www.securityspace.com and
www.netcraft.com (costs money for what securityspace gives
for free).  Of these, start at [2].

(Which shows the penetration of SSL in websites has risen
from about 1% to 1.2% since the beginning of the year.
Although, there are now new figures on there that show
that only 31% of the 141k found are valid / self-signed
certs.)

In terms of other uses of PKI, outside HTTPS, I don't
know any regular surveys.  I imagine it would be too
depressing to conduct more than once :)

 How many shops do use SET for payment?

Is SET still alive?  Available?  The crypto-based payments
field appears to be quiet at the moment (e.g., payments
that are not done over HTTPS).

About the only thing that I know of (other than own stuff)
is peppercoin which seems to be a DRM micropayments play.
Poking around on the website, it appears to be a crypto
download microtoken billing method, that is aggregated
onto credit cards or bank accounts [3].  IOW, a grab bag
of payments techniques that appears blithely ignorant of
the last decade in digital payments.

iang

[1] http://www.openssh.com/usage/ssh-stats.html

[2] http://www.securityspace.com/s_survey/sdata/200308/domain.html
[3] 
http://www.peppercoin.com/General/FAQAnswerPage.ppp?keyID=helpfaq/faqs/AboutPeppercointopicIndex=16

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: invoicing with PKI

2003-09-02 Thread Hadmut Danisch
On Mon, Sep 01, 2003 at 12:23:28PM -0400, Ian Grigg wrote:

 The dream of PKI seems to revolve around these major areas:
 
   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)
 
 In terms of actual deployed PKIs, the only significant
 cases that I know of, deployed outside of organisations
 and in widespread use are:
 
HTTPS (141k, see below), and
OpenPGP (millions says PGP Inc, so let's call it 100k or so).
 


The reason I was asking is: I had a dispute with someone who
claimed that cryptography is by far the most important discipline
of information and communication security, and that its transition
from an art to a science was triggered by Shannon's paper in 1949
and the Diffie/Hellman paper in 1976 (discovery of public key
systems).

Reality is different: While Firewalls, Content Filters (Virus/Spam/
Porn filters), IDS, High availability systems, etc. become more and
more important, encryption and signatures, especially based on PKIs, 
don't seem to get more relevant (except for HTTPS/TLS).

There was an interesting speech held on the Usenix conference 
by Eric Rescorla (http://www.rtfm.com/TooSecure-usenix.pdf, 
unfortunately I did not have the time to visit the conference)
about cryptographic (real world) protocols and why they failed
to improve security. From the logfiles I've visited I'd estimate
that more than 97% of SMTP relays do not use TLS at all, not
even the oportunistic mode without PKI. 

I actually know many companies who can live pretty well and secure
without cryptography, but not without a firewall and content filters.
But many people still insist on the claim that cryptography is by far
the most important and only scientific form of network security.

provocation
Is cryptography where security took the wrong branch?
/provocation

regards
Hadmut

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: invoicing with PKI

2003-09-02 Thread Anne Lynn Wheeler
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
http://www.garlic.com/~lynn/2003l.html#33 RSA vs AES
background
http://www.garlic.com/~lynn/2003l.html#24 RSA vs AES
http://www.garlic.com/~lynn/2003l.html#27 RSA vs AES
http://www.garlic.com/~lynn/2003l.html#28 RSA vs AES
http://www.garlic.com/~lynn/2003l.html#32 RSA vs AES
when we were working with small client/server startup for payments
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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.
http://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.
http://www.garlic.com/~lynn/subtopic.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:
http://www.garlic.com/~lynn/index.html#x959

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

--
Anne  Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]