Subject: [pkix] Which is the new KPI research that is telling us how PKI is going on?

From: Roberto Opazo <[email-masked]>
Date: Sat, 23 Jul 2011 12:00:45 -0400

Hello people:

Could you please give me some references to have a real, objective
opinion about this important question for all of us?

Is PKI going well?

I’m looking for researches that show PKI growing in the world, but I’m
not been lucky. I’m founding a lot of pessimism and it seems PKI is
growing more in my very small and far country (Chile) than in the rest
of the world.

If you Google “pki statistics” or “pki growing”, there are not obvious
references and there are a lot of very old researches.

Which is the new PKI research that is telling us how PKI is going on?

-- 
Best regards,

Roberto Opazo
Consulting partner at Vyreal Consulting Group
www.vyreal.com

---

From: Massimiliano Pala <[email-masked]>
Date: Sat, 23 Jul 2011 14:55:50 -0400

> Which is the new PKI research that is telling us how PKI is going on?

I would say that PKIs have now become the required building block for
strong authentication and communications both on the Internet and
for industry/companies/organizations. Indeed, all the auth systems
that today implement "strong" authentication rely on public-key
technology (e.g., governments, cloud and grid computing, etc.).

What we need today is to provide a support system for PK for the
Internet that would allow simple interactions among parties that
use this technology.

Cheers,
Max

-- 

tel.718-260-4009 | web: http://member.acm.org/~openca/

Massimiliano Pala, Ph.D.
Director, OpenCA Labs
Professor, NYU Poly

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 23 Jul 2011 22:04:48 +0200

> opinion about this important question for all of us?

Hello Roberto!

I think that anyone claiming to be objective is liar so here is
a list of what I call "PKI hurdles".

The Microsoft Problem #1:
========================
Assume you have an organization with AD running in W2K8SR2
and all clients run W7SP1. Now one would believe that buying
a bunch of smart cards and connecting to "CertServ" would be
all that it takes, right?  No way!  Self-service?  No way!

You need a *very pricey consultant* and tons of alien software.

Why would anybody except cost-insensitive government agencies
put up with that?

The Consumer PKI Problem:
=========================
Assume that your country have issued e-IDs for their citizens.
But the computers are not equipped with card readers!
- Who are supposed to pay for readers?
- Who is supposed to pay for a card when hardly any bank accepts it?

The On-line Bank Problem #1
===========================
On-line banks often want to use PKI but have in spite of being
(usually...) among the richest organizations in the world, not
spent a cent on developing a dirt-cheap USB-token that fits into
their clients' computers.

The On-line Bank Problem #2
===========================
Due to On-line Bank Problem #1 they typically try "soft" PKI.  Then they
pretty immediately run into Microsoft Problem #2 which is that "CertEnroll"
is piece of junk and therefore *they are forced developing their own software*
which of course cause major support issues and skyrocketing costs.

The SDO Problem:
================
Standards groups concentrate on small things they understand and
therefore protocols are typically disconnected from the middleware
which in turn is disconnected from the hardware.

So it is all darkness and gloom?

Absolutely not!
Fortunately there are new vendors that sell amazingly popular computing
devices that can be easily deployed with PKI without adding any additional
client software or hardware:

http://images.apple.com/iphone/business/docs/iPhone_OTA_Enrollment_Configuration.pdf

I could add lots of other things but e-mail isn't for writing novels :-)

Best,
Anders

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 24 Jul 2011 15:49:27 +1200

Roberto Opazo <[email-masked]> writes:

>Is PKI going well?
>
>I=92m looking for researches that show PKI growing in the world, but I=92m
>not been lucky.

You already have your answer: You're looking for evidence that PKI is doing
well, and haven't found much (or possibly any).  Your question has been
answered.

Peter.

---

From: Stephen Wilson <[email-masked]>
Date: Sun, 24 Jul 2011 14:10:10 +1000

Roberto,

I believe the reason PKI looks ill still is that there are two different 
interpretations of the word.

(1) Some use the word PKI to mean a system where a third party CA issues 
certificates for "identification" usually for a fee.  This is the 
original vision of PKI from the early 1990s.  It almost universally 
failed.  Notably, post offices worldwide (including US, Australia, Hong 
Kong, Malaysia and I think the UK) tried in vain to make money selling 
certificates.  Steve Kent has called these "Big CAs".

This model failed mainly because it turns out that general purpose 
identity certificates are pretty much useless.  Authorisation in 
e-business is more important than authentication (see e.g. 
http://lockstep.com.au/blog/2011/01/22/forget-authentication).   As 
Steve Kent also pointed out, Big CAs acted as though there is only one 
'true identity'.  All a Big CA can do is check personal identity but in 
real e-business, diverse digital identities are more important: e.g. 
employee number, professional licence number, association membership, 
account number, customer reference number etc.  Big CAs cannot easily 
verify these.

There is one arguable exception to the rule that Big PKI failed: SSL 
server certificates.  Clearly these proved to be a sustainable business.

(2) Some use the work PKI to refer to the technology of X.509 
certificates (and other standards), CA servers, RAs, key media and so 
on.  There are many applications and business environments where PKI 
technology and special purpose certificates are working very well.  I 
have long argued that "closed" PKI is the _general_ use case and that 
"open PKI" (with general purpose identity certificates) is a very 
special case with very little point (see 
http://lockstep.com.au/library/pki/public_key_superstructure).

Some examples of successful closed PKIs:

- ICAO electronic passports
- Chip-and-PIN EMV DDA smartcards
- health smartcards like Sesame Vitale (France)
- healthcard provider smartcards in Taiwan, Austria and Australia
- Skype
- PIV cards
- CAC (military ID cards) in US and Australia.

So PKI is thriving, if you know where to look, and if we abandon the 
strawman idea of general purpose identity certificates.

Cheers,

Stephen Wilson
Managing Director
Lockstep Group

Phone +61 (0)414 488 851

http://lockstep.com.au <http://www.lockstep.com.au>
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 24 Jul 2011 16:27:39 +1200

Stephen Wilson <[email-masked]> writes:

>There is one arguable exception to the rule that Big PKI failed: SSL server 
>certificates.  Clearly these proved to be a sustainable business.

It depends what your success criteria are, it's a very successful business 
model (because it's a pure protection racket, "pay us money or your customers 
will be scared away by browser messages") so everyone has to pay a CA in order 
to run a business online (or at least one that uses SSL), but not a very 
successful security model (it does basically nothing to defeat phishing).  My 
favourite example of SSL PKI in practice is:

  https://secondzion1.com/

(one of many, many similar sites).  If you're nervous about going there, it's
a site that trades in:

  Sale / Purchase of carding stuff, Sell CC + CVV. Enroll (COBs, full info). 
  Sell & Buy accounts: banks, PP, MB and more. Search SSN, DOB, credit reports 
  etc. ATM. Any cashout. Exchange, purchase, electronic currency. Drops for 
  stuff. Hosting, servers, spam, adult and call services. Credit card fraud 
  for sale topical working order. Selling online stores for online carding etc.

and it's been certified by a commercial CA.  In other words the CAs are issuing
certificates to the very criminals that they're supposed to be protecting us
from.

>There are many applications and business environments where PKI technology and 
>special purpose certificates are working very well.  I have long argued that 
>"closed" PKI is the _general_ use case and that "open PKI" (with general 
>purpose identity certificates) is a very special case with very little point 

I'd label that model the COI (community-of-interest) PKI, and that is a model 
that works: everyone signs up and agrees to play by the rules of the 
community, reponsibility and liability are allocated, and so on.

>So PKI is thriving, if you know where to look, and if we abandon the strawman 
>idea of general purpose identity certificates.

Unfortunately the strawman concept is still extremely popular (or maybe it's 
the "PKI as a silver bullet" concept), and for many users it's the only one 
that exists.  It's unfortunate that there's not a stronger distinction drawn 
between the two...

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 24 Jul 2011 07:29:11 +0200

Roberto,

That you can't buy a token for lets say $10 at an ordinary
supplier of computers, in a form-factor that fits existing
computers (USB), connect to a CA using a standard browser,
and after some kind of authentication/authorization process
get a certificate in the token, limits "PKI for individuals"
to organizations with very "deep pockets" and ample of time.

FWIW, I'm running (as a hobby) the currently only publicly
known project for rectifying this situation.

The project builds on a combination of Open Software and
Open Hardware.  Initially I tried to use standard smart cards
but in most cases you cannot even get a datasheet (!) without
an NDA, so it uses standard electronics.

The tokens will be produced in China and India who haven't
signed the http://www.wassenaar.org/participants/index.html
treaty so there will be no limits.

The idea is simply making PKI "a better password".

Anders

---

From: Stephen Wilson <[email-masked]>
Date: Sun, 24 Jul 2011 17:11:47 +1000

Anders,

What do you imagine such a certificate would be used for?  What exactly 
will the certificates mean to any Relying Party?  "This is [probably] 
Anders Rundgren, so says some CA [see fine print]"?

On the other hand, there actually are dozens of different 
certificates-for-individuals issued in closed communities of interest 
for special purposes.  I have many personal certificates embedded in my 
Chip-and-PIN cards, my passport, my cell phone, my Skype client etc etc.

There is no conspiracy behind the failure of open PKI.  Rather, the fact 
is that there is no precedent in the real world for a single general 
purpose identity.  There is no social/legal infrastructure for 
supporting such a thing, no demand for it, and plenty of privacy-related 
objections to ever really having it.

Cheers,

Steve.

Stephen Wilson
Managing Director
Lockstep Group

Phone +61 (0)414 488 851

On 24/07/2011 3:29 PM, Anders Rundgren wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>
>

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 24 Jul 2011 10:37:06 +0200

On 2011-07-24 09:11, Stephen Wilson wrote:
> 
> Anders,
> 
> What do you imagine such a certificate would be used for?  
> What exactly will the certificates mean to any Relying Party?
> "This is [probably] Anders Rundgren, so says some CA [see fine print]"?

Stephen,

This is a container solution.  The "CA" I mentioned would in an
enterprise setting be your local enterprise CA who's certificates
would be used as passwords are used today.  The difference compared
to current solutions is that this concept works equally well if
the enterprise has 10 or 100 000 employees although the authorization
methods may surely differ.

Also in contrast to current solutions the very same token can host
hundreds of certificates belonging to different communities.

I imagine that the e-governments and on-line banks in the EU having
issued tenth of millions of "soft" certificates could consider
using such a token if it (=whole "stack") reaches the state of
commoditization needed for this to actually make sense.

By increasing the end-user price with $1 the functionality could be
added to USB memory sticks.  Although this has been tried without
success earlier, the predecessors IMHO were too focused on the
business model, like charging money for each enrolled credential!!!

Note: This concept in no way competes with passports, healthcards,
EMV and similar centrally produced cards.

NSTIC is an interesting in-between scheme where there probably will
be a clash with the "traditionals".

Last but not least: The scheme is intended to work identically in
enhanced mobile phones.

This is not a research project, vendor solution, or standardization
effort.  It is an attempt establishing an "industry" standard through
an open implementation which runs all the way from browser, protocol,
and middleware down to low-level crypto and electronics.

Cheers,
Anders

> On the other hand, there actually are dozens of different certificates-for-individuals issued in closed communities of interest for special purposes.  I have many personal certificates embedded in my
> There is no conspiracy behind the failure of open PKI.  Rather, the fact is that there is no precedent in the real world for a single general purpose identity.  There is no social/legal infrastructure
> for supporting such a thing, no demand for it, and plenty of privacy-related objections to ever really having it.
> 
> Cheers,
> 
> Steve.
> 
> Stephen Wilson
> Managing Director
> Lockstep Group
> 
> Phone +61 (0)414 488 851
> 
> on digital identity and privacy.  Lockstep Technologies develops unique

---

From: Massimiliano Pala <[email-masked]>
Date: Sun, 24 Jul 2011 17:03:47 -0400

Hello Stephen, Roberto, all,

I would like to point out that even if authorization is usually what you want
to achieve, it always starts with authentication. Be it via a simple
Password, Key, Keypair, or a key+certificate.

My point being, public-key technology is actually used as the basic block
of any strong authentication *and* authorization system today.. because the
technology itself works!

One thing we shall all work for now, is to make this technology easier to
deploy in open environments and/or allow for easy federated identities. In
this space, I think, there's a lot of work to do (and we should have worked
at it earlier!).

Personally, I think that the next step in PKIs, since this is the technology
we are using today and are going to use in the next 20/30 years, is to provide a
support system for it that will allow the "closed" environment success to
be extended to the "open" environment.

One point that I agree here with is that generic-pkis do not really have
traction, but purpose oriented ones or "closed" ones that are going to be
federated (e.g., Grid Computing) are really successful (world wide: look at
TAGPMA, IGTF, EUPMA, etc.)

A lot of work has been done in the standardization of the certificates
(although sometimes we got lost on very.. small details!), but
now we need to provide a common ground that can ease the usage of public
key technology for the Internet (after all, we have a DNS.. but we don't
have a support system for PK... why?!?!?!).

An example of the lack of support for PK is the deployment of DNSSEC:
everybody agrees that's not the best solution.. but there's nothing better
available today that could foster interoperable ``Internet'' security.

Anybody on-board to start this huge-but-needed project ? Maybe a new
WG like `Support (System) for Internet Trust Infrastructures` could
provide a good starting point ?

Cheers,
Max

On 07/24/2011 12:10 AM, Stephen Wilson wrote:
>
> Roberto,
>
> I believe the reason PKI looks ill still is that there are two different interpretations
> of the word.
[...]
> (2) Some use the work PKI to refer to the technology of X.509 certificates (and other
> standards), CA servers, RAs, key media and so on.  There are many applications and
> business environments where PKI technology and special purpose certificates are working
> very well.  I have long argued that "closed" PKI is the _general_ use case and that "open
> PKI" (with general purpose identity certificates) is a very special case with very little
> point (see http://lockstep.com.au/library/pki/public_key_superstructure).
[...]
> So PKI is thriving, if you know where to look, and if we abandon the strawman idea of
> general purpose identity certificates.

-- 

Massimiliano Pala, Ph.D.
Director, OpenCA Labs
Professor, NYU Poly

---

From: Massimiliano Pala <[email-masked]>
Date: Sun, 24 Jul 2011 17:13:59 -0400

On 07/24/2011 12:27 AM, Peter Gutmann wrote:
> Stephen Wilson<[email-masked]>  writes:
[...]
> favourite example of SSL PKI in practice is:

I would argue that that's more a failure of who is designing and developing
applications rather than who's issuing the certificates. Since the usability
of applications from this point of view is ridiculous, I would blame browser
vendors rather than PKIs in general - they failed their users with respect of
usability.

Think about the case where simple http connections (no SSL/TLS) are displayed,
to the user, more trustworthy than non-trusted https (SSL/TLS) once.. Bad.. Bad..
Bad.. browsers and who took such bad decisions.. !!!

[...]
> certificates to the very criminals that they're supposed to be protecting us

Commercial CAs have their flaws, some are better than others. But since the user
has no way to distinguish among them (e.g., they are forced to trust all of them
at once by the application vendors!!!), it is quite scary!

[...]
> community, reponsibility and liability are allocated, and so on.

That's the way it is supposed to be: the user capable of saying "now I want to
submit my tax returns to my gov agency, I want to trust only that!" or "now I
am at work, trust my organization's CA to authenticate my colleagues". And,
of course, extending it to the federated-identities case...

Community-Driven + Interoperability and Availability in the Internet is the
key in today's online world (or, otherwise called, Internet of things...).

Just my 2 cents...

-- 

Massimiliano Pala, Ph.D.
Director, OpenCA Labs
Professor, NYU Poly

---

From: Roberto Opazo <[email-masked]>
Date: Sun, 24 Jul 2011 23:26:47 -0400

Thanks everybody.

Yes, my question was too wide.

I’m thinking in PKI used to authenticate people. Not web servers or
invisible certificates for devices or applications.

I would like to share the Chilean experience in a few points and numbers:

*	5 CA’s certified by government to sign (sell) trustable
certificates. This is to certify people in an open national PKI.

*	About 60.000 issued certificates. Sounds few, but it’s not so small
number in a country with less than 200.000 companies with
accountability.

*	Companies using electronic invoice: 33.000. All of them interchange
their documents in an electronic way.

*	Examples of documents than are been digitally signed: Electronic
Invoices, technical reviews of vehicles, insurance policies,
environmental impact assessments, factoring, book works and some
others.

*	Even some banks are madding poor act of presence using certificates
with a small group of customers.

I still can’t believe there is no research about global use of X.509
people certificates.

-- 
Saludos,

Roberto Opazo

---

From: Max Pritikin <[email-masked]>
Date: Sun, 24 Jul 2011 21:41:45 -0600

> There are many applications and business environments where PKI technology and special purpose certificates are working very well.  [Stephen Wilson has] long argued that "closed" PKI is the _general_ use case and that "open PKI" (with general purpose identity certificates) is a very special case with very little point

+1, I think this is a very important point.

Even in that context client certificate use has lagged behind server certificate use. 

- max

On Jul 23, 2011, at 10:10 PM, Stephen Wilson wrote:

> 
> Roberto, 
> 
> I believe the reason PKI looks ill still is that there are two different interpretations of the word.  
> 
> (1) Some use the word PKI to mean a system where a third party CA issues certificates for "identification" usually for a fee.  This is the original vision of PKI from the early 1990s.  It almost universally failed.  Notably, post offices worldwide (including US, Australia, Hong Kong, Malaysia and I think the UK) tried in vain to make money selling certificates.  Steve Kent has called these "Big CAs". 
> 
> This model failed mainly because it turns out that general purpose identity certificates are pretty much useless.  Authorisation in e-business is more important than authentication (see e.g. http://lockstep.com.au/blog/2011/01/22/forget-authentication).   As Steve Kent also pointed out, Big CAs acted as though there is only one 'true identity'.  All a Big CA can do is check personal identity but in real e-business, diverse digital identities are more important: e.g. employee number, professional licence number, association membership, account number, customer reference number etc.  Big CAs cannot easily verify these.  
> 
> There is one arguable exception to the rule that Big PKI failed: SSL server certificates.  Clearly these proved to be a sustainable business. 
> 
> 
> (2) Some use the work PKI to refer to the technology of X.509 certificates (and other standards), CA servers, RAs, key media and so on.  There are many applications and business environments where PKI technology and special purpose certificates are working very well.  I have long argued that "closed" PKI is the _general_ use case and that "open PKI" (with general purpose identity certificates) is a very special case with very little point (see http://lockstep.com.au/library/pki/public_key_superstructure).  
> 
> So PKI is thriving, if you know where to look, and if we abandon the strawman idea of general purpose identity certificates. 
> 
> Cheers, 
> 
> Stephen Wilson
> Managing Director
> Lockstep Group
> 
> Phone +61 (0)414 488 851
> 
> http://lockstep.com.au

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Jul 2011 16:24:33 +1200

Roberto Opazo <[email-masked]> writes:

>I still can=92t believe there is no research about global use of X.509 people
>certificates.

Ah, now that you've narrowed the scope down, it is possible to answer your
question.  There's been quite a bit of research into this by HCI people (so
you've probably been looking in the wrong place for information).  The
consensus is that client-side/end-user PKI is effectively impossible to use by
most users.  There have been various proposed alternative ways of dealing with
certs that (according to the researchers) are usable, but none of them have
ever been adopted.

The first study in this area that I know of, "In Search of Usable Security:
Five Lessons from the Field" by Balfanz, Durfee, Grinter and Smetters, carried
out with highly technical users (mostly PhDs in computer science), found that
they took over two hours to set up a certificate for their own use, and rated
it as the most difficult computer task they'd ever been asked to perform.
There have been numerous further studies by HCI people since then, with
roughly the same results.  So you need to look at HCI publications, not 
standard security ones, for information.

Peter.

---

From: Stephen Wilson <[email-masked]>
Date: Mon, 25 Jul 2011 14:22:42 +1000

Roberto,

I think you will find comparable systems in ...

- Scandinavia, using the "BankID" technology in cooperation between 
banks and governments
- Taiwan, where they have had a government issued PKI smartcard for B2G 
transactions for a long time
- Parts of Europe where e-invoicing using EU Qualified Digital 
Signatures and keys (maybe Italy)

In many places like Australia, simple B2G transactions like tax returns 
etc. have operated with simpler cheaper authentication technologies.  
Where there is just one Relying Party, the advantages of PKI are less, 
because it is straightforward to manage risk via shared secrets.

But it sounds like the Chilean experience is quite strong.  Is your 
system growing or is it stagnant?

Cheers,

Steve Wilson
Lockstep
http://lockstep.com.au

On 25/07/2011 1:26 PM, Roberto Opazo wrote:
> 2011/7/24 Massimiliano Pala<[email-masked]>:

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Jul 2011 16:28:41 +1200

>Even in that context client certificate use has lagged behind server

The reason why client certs have seen next to zero adoption is because of the
issues given in my previous message.  For server certs you get your sysadmin
to set up the single cert that's needed in a once-a-year effort, and if it
takes him (usually a 'him' :-) two days of work to sort out then that's OK.
That just doesn't work for end-users.  Client-side certs aren't used because
they don't work (at the HCI level), not because of any organised action to
avoid them.

Peter.

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 25 Jul 2011 00:43:45 -0400

> Bad.. browsers and who took such bad decisions.. !!!

Read https://bugzilla.mozilla.org/show_bug.cgi?id=566008#c10 and you
will understand why this is.

-- 
Matt

---

From: Roberto Opazo <[email-masked]>
Date: Mon, 25 Jul 2011 00:45:05 -0400

Peter, Stephen:

Thanks a lot I’ll follow this references.

-- 
Saludos,

Roberto Opazo

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Jul 2011 16:49:04 +1200

>vendors rather than PKIs in general - they failed their users with respect of

Oh, absolutely.  The CAs aren't in business for their health, they're in
business to return a profit to shareholders.  The way to do this is to
minimise expenses (the less checking you do, the better) and maximise revenue
(the more certs you sell, the better).  I'm not faulting them for that, it
would be economically irrational to run your business in any other manner.
The problem isn't really the CAs, it's the browser vendors.  According to the
browser vendors, the only thing that can indicate "goodness" for a site is
whether they've got a certificate.  No matter how diligent and scrupulous a CA
is in checking sites, the browsers treat their certs identically to the most
negligent, unscrupulous CA of the lot (which incentivises the race to the
bottom that we've already seen).  What's more, any browser will happily take
users to a site claiming to belong to a major bank that's hosted on a botnet
running on a Windows XP Home machine in Kazakhstan and that contains drive-by
Javascript-driven malware (pretty much every warning sign you can think of),
but the only time they'll bother raising an alarm is if the site contains a
non-commercial-CA-signed cerficate.

(Blatant self-promotion: I'm doing a talk on this problem at EuroPKI in just
over a month :-).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Jul 2011 17:25:28 +1200

Stephen Wilson <[email-masked]> writes:

>- Scandinavia, using the "BankID" technology in cooperation between banks and
>governments

I'm not sure I'd use BankID as a good example, see "Weaknesses in BankID, a
PKI-Substitute Deployed by Norwegian Banks" by Kristian Gjøsteen and "Risk
Assessment of a National Security Infrastructure" by Kjell Hole et al.  BankID
is a quite bizarre infrastructure, the story I heard was that they intended to
deploy client-side PKI, found it was more or less impossible, and then because
of the existing investment couldn't throw away the PKI stuff so they buried it
where it wouldn't have any effect while still being able to claim they were
using PKI.

Actually it's more a counterexample to client-side PKI use :-).

>- Parts of Europe where e-invoicing using EU Qualified Digital Signatures and
>keys (maybe Italy)

That hasn't been such a success either.  In Germany it's often preferable to
do an end-run around the system than to jump through its endless hoops (I have
refs for the numerous creative ways that users have come up with this, but
they're all in German).

>transactions for a long time

I don't have any third-party info on how well this is really doing in
practice.

I guess a generalisation of the above is that you'd need to look at third-
party assessments of how something actually works, not reports by the people
running the thing.  In all of the above there are glowing assessments by the
managers telling everyone how good a job they've done, and then when you look
at independent, third-party assessments or user feedback on actually using the
system you get a very different story.

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 07:43:37 +0200

BankID in Norway use server-side versions of client-PKI
and let the users authentication with OTP or similar.

BankID in Sweden use client-side PKI but since the "PC" platforms
vendors do not support on-line enrollment of certificates
in a reasonable way ("there is no business case"), they
write their own browser PKI client and they are by far not
alone doing that.

There's obviously an *ocean* separating the different parties.

This is the main motivation behind for the project earlier mentioned.
Rather than waiting for the PKI equivalent of the middle-east conflict
to end, "under the radar" build something that actually works!  :-)

Anders

---

From: Stephen Wilson <[email-masked]>
Date: Mon, 25 Jul 2011 16:07:20 +1000

Peter: I certainly agree that BankID is problematic. I was only using it 
as an example of the vanilla personal certificate programs that Roberto 
is looking for.  I maintain that none of these generic "Big PKI" 
programs are really very useful.  Experience shows that no CA is going 
to warrant general purpose certificates for a nice wide range of apps.  
A particular limitation of BankID is that it has achieved a restricted 
form of federation between banks and governments by way of legislation.  
I suspect that it is riddled with fine print.

Anders: I must say I find your rhetorical metaphors about the middle 
east, oceans and radars very confusing.  Many of us are frustrated with 
(or bemused by) conventional PKI, but can we speak in plain language, 
not riddles please?

I agree there are hardware and operating system level interoperability 
problems, and getting smartcards to work is not as easy as it should 
be.  But I also remember when printers did not plug and play, and I 
remember when CDs had to be burned using special equipment.  These 
problems were solved over time.  I believe that the plastic card is such 
a universally easy to use form factor that in time, PC and OS vendors 
will solve these niggly issues, and that we will be able to do things 
like (a) pop an EMV card into a slot and do POS transactions over the 
Internet, or (b) use a smart health card to securely access Personal EHRs.

See also http://www.abc.net.au/tv/newinventors/txt/s2423212.htm.

Cheers,

Steve Wilson

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 08:33:21 +0200

> (or bemused by) conventional PKI, but can we speak in plain language, 

No riddles here:
http://www.ietf.org/mail-archive/web/pkix/current/msg29497.html

> See also http://www.abc.net.au/tv/newinventors/txt/s2423212.htm.

Vendors are no better that their customers and for PKI the USG is primary
customer (seen from a US vendor perspective) and the USG buys essentially
one vendor's client OS.  Combining the slowest customer group you can find,
with a space where there is no competition doesn't exactly spur progress.

The USG doesn't care s--t about consumer PKI, they never had such a program.
I.e. "there is no business case".  I heard it directly from the PMs so I
should know...

Naturally there will be local suppliers of unique solutions like BankID
but how interesting is this?

You are working in another segment, be happy for that :-)

Anders

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 25 Jul 2011 09:57:21 +0200

hi,

> - Parts of Europe where e-invoicing using EU Qualified Digital Signatures and keys (maybe Italy)
last year a EU directive 2006/112/EC amendment as removed the requirement
for signatures (I guess because of the high percentage of electronic invoices
that are exchanged since decades without anything like that).

/The authenticity of the origin, the integrity of the content and the legibility of an invoice, 
whether in paper or in electronic form, shall be ensured from the point in time of issue until the 
end of the period for storage of the invoice. This may be achieved by any business controls which 
create a reliable audit trail between an invoice and a supply of goods or services/

Peter

---

From: George Michaelson <[email-masked]>
Date: Mon, 25 Jul 2011 04:08:57 -0400

ATO PKI in Australia is not mandatory. You can manage to find intermediaries to work on your behalf without having first-class direct entry access only via PKI. (willing to be corrected on that one, but thats my current understanding. It may differ for BI level tax operations but when I did GST submit for a not-for-profit and that was AFTER PKI rollout, I didn't need to use the PKI to submit my GST returns then)

at least one Australian client-side bank PKI was mandated 'we make the keys' which shipped to you on a 3.5" floppy. A frisson there. Thank goodness for the security of write-enable tabs! (not)

I think the HCI factors are true. Whoever posted "there is no logout" said something which has been nagging me for years and years. Why are all browsers so crap at letting you securely dis-associate from your bindings made with your ID?

I have also recently been musing on the shipped list of TA. Its unfair to objectify a single recent TA installation. In fact, I think we've been terribly remiss in accepting ab-initio ANY installed TA state. Classic chicken-and-egg: nobody was going to accept the HCI implications of hand installing an OOB TA blob, but we've wound up blithely *believing* the 'trusted' flags which emit from a system which pre-shipped to us with certain assumptions wired in that are never exposed to us in a way we can really make sense of.

As an ex-GOSIP days OSI person, can I make one plea to remind people some behaviours in this space vest from models of what we think we know about structured nameforms from a time when the global Internet was counted in thousands, and scaling problems related to the 3M computer: a Meg of memory, a Megapixel and 1 MHZ of CPU...

-G

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 25 Jul 2011 20:28:04 +1200

Peter Sylvester <[email-masked]> writes:

>/The authenticity of the origin, the integrity of the content and the
>legibility of an invoice, whether in paper or in electronic form, shall be
>ensured from the point in time of issue until the end of the period for
>storage of the invoice. This may be achieved by any business controls which

Thus the suggestion made in one German article on the topic that the most
effective actual mechanism for complying with the law is (and I quote):

  find <path> | xargs cat | lpr

(from "Gesetzgeber laesst Anwender im Regen stehen", Nils Magnus).

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 25 Jul 2011 10:59:54 +0200

On 2011-07-25 10:08, George Michaelson wrote:
<snip>
> I think the HCI factors are true. Whoever posted "there is no logout" said
> something which has been nagging me for years and years. Why are all
> browsers so crap at letting you securely dis-associate from your bindings
> made with your ID?

Here is my take on your question:

- The browser vendors have mainly US origin

- Their primary "home market" for PKI is the US Government

- The US government isn't working with "PKI for people" but with things
  that are more related to Homeland Security

The USGs newly formed NSTIC program will fail unless they understand that
what you call the HCI factors, needs a lot more attention, maybe even
fundamental changes in schemes that security experts claim are "ready".

HTTPS using client certificates will IMO never become mainstream unless
the protocol is augmented with an interoperable logout solution.  This
may not be a problem because many deployers have already replaced this
with "homebrewed" solutions since they anyway was forced writing their
own enroll and signature solution.

<snip>

Anders

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 25 Jul 2011 14:26:32 -0400

> invisible certificates for devices or applications.

I support a 10+ year old X.509 PKI with 4+ million users performing multiple authentication operations per day in many different contexts, from site and system authentication to legal document signing.  But even with multiple bridging arrangements it's still accurate to call it a closed community.

Success is all in how you measure.

-- T

---

From: Stephen Wilson <[email-masked]>
Date: Tue, 26 Jul 2011 04:48:51 +1000

On 26/07/2011 4:26 AM, Miller, Timothy J. wrote:
> I support a 10+ year old X.509 PKI with 4+ million users performing 
> multiple authentication operations per day in many different contexts, 
> from site and system authentication to legal document signing. But 
> even with multiple bridging arrangements it's still accurate to call 
> it a closed community.
No "buts"!

At some scale, and in some dimension, all applications are closed.  For 
instance, the Visa/MasterCard system is closed even if it covers the globe.

Closure is a good thing!  We need boundaries on what digital 
certificates mean, and what they may be used for.

The vain pursuit of "open" PKI is one of the things that made Big PKI 
overly complicated, and it still distracts people.  People think PKI has 
failed because you cannot get a certificate that proves who you are 
without qualification on every cyber domain.

Cheers,

Steve Wilson
Lockstep
http://lockstep.com.au/library/pki

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 25 Jul 2011 18:10:04 -0400

WARNING: contains banned part

Subject: RE: [pkix] Which is the new KPI research that is telling us how PKIis going on?
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Date: Mon, 25 Jul 2011 18:10:04 -0400

-----Original Message-----
From: George Michaelson

> I think the HCI factors are true. Whoever posted
> "there is no logout" said something which has been nagging
> me for years and years. Why are all browsers so crap at
> letting you securely dis-associate from your bindings made
> with your ID?

Of course there is a logout - just kill the browser and restart it :-).

I have no idea why, when browsers now support a "no history" private
browsing mode in addition to the traditional cookie/history wipe, there
couldn't also be a TLS state wipe (with or without deactivating the
keystore) - it would be a trivial piece of UI to implement.  

> I have also recently been musing on the shipped list of TA.
> Its unfair to objectify a single recent TA installation.
> In fact, I think we've been terribly remiss in accepting
> ab-initio ANY installed TA state. Classic chicken-and-egg:
> nobody was going to accept the HCI implications of hand
> installing an OOB TA blob, but we've wound up blithely
> *believing* the 'trusted' flags which emit from a system
> which pre-shipped to us with certain assumptions wired in
> that are never exposed to us in a way we can really make
> sense of.

On what basis can an individual make a decision to trust *anything*,
including a news article with an AP byline, or a tweet from someone with
a name that seems familiar?  This is not an HCI issue, it's a human
nature issue.  Organizations are in a somewhat better position to
establish criteria that must be met before extending trust to an
partner, and audited in order to maintain the relationship.  

It's unfair to object to "blithely believing" something related to PKI
in particular - we all are exposed to new information every day, and we
subject it to varying degrees of cynicism and analysis, but we never
formally establish personal criteria for acceptance of *anything*.

The inconvenience of installing OOB TA blobs is unrelated to trust.  A
system could be shipped with TAs present but unflagged, and a set of
"manufacturer-approved" flag settings. Importing a new TA to the
unflagged list should be trivial.  But the user still has the problem of
deciding to flag each one separately (based on what?) or accepting the
manufacturer default list (also based on what?).

Dave

---

From: Max Pala <[email-masked]>
Date: Mon, 25 Jul 2011 16:18:21 -0600

Hi Matt,

I understand what the browser vendors point of view is. The problem is the assumption that to users can give any value to https:// vs http:// . Plenty of research demonstrated that that is not true. One of the few elements that users can recognize is the lock.. Not the protocol identifier.

After all, encrypting contents to an "unknown" or "unveriifed" party is no different than not encrypting it at all. That's the point. It is still an "untrusted" connection.. Exactly as an http:// one.

If browser vendors implemented the concept of trusted/not-trusted not based on just an "s" the world could have been a better place.. But, and this is my speculation, the real reason behind this choice was liability (and probably some influence from commercial CAs, not security..). An example o this.. EV certs..

Just my 2 cents..

---

Cheers,
Max

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 26 Jul 2011 15:14:32 +1200

Max Pala <[email-masked]> writes:

>After all, encrypting contents to an "unknown" or "unveriifed" party is no
>different than not encrypting it at all. That's the point. It is still an
>"untrusted" connection.. Exactly as an http:// one.

That's a misconception created (or caused) by crypto purists.  In one of the
few real cases where encryption of HTTP traffic would actually be useful,
802.11 sniffing/Firesheep-style attacks, encryption with anon-DH (which SSL
PKI is in effect anyway, as you point out the only real indicator is
padlock/no padlock which anon-DH gives you just as well) would be enough to
stop the attack dead in its tracks.

Peter.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 26 Jul 2011 09:03:18 -0400

Concur.  Confidentiality without authentication has plenty of uses.

-- T

---

From: Yoav Nir <[email-masked]>
Date: Tue, 26 Jul 2011 16:37:46 +0300

If nothing else, it makes the attacker work harder.

It's very easy to listen in on HTTP in the LAN or the WLAN. It's feasible even out of the LAN
Go to HTTPS and you need to be an active attacker. That's a whole different level of effort.

On Jul 26, 2011, at 9:03 AM, Miller, Timothy J. wrote:

> <smime.p7s><ATT00001..txt>

---

From: Max Pritikin <[email-masked]>
Date: Tue, 26 Jul 2011 13:43:22 -0400

On Jul 23, 2011, at 4:04 PM, Anders Rundgren wrote:
[snip]
> http://images.apple.com/iphone/business/docs/iPhone_OTA_Enrollment_Configuration.pdf

Anders, Thanks for the continued notes of encouragement concerning the iPhone enrollment mechanisms. We designed that based on our Cisco VPN router deployment solution and the lessons we learned in the process have directly informed the EST draft.

I too agree it is not all "darkness and gloom".

I appreciate the continued feedback,

- max

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 26 Jul 2011 14:57:17 -0600

Hi all,

Well.. Sort of... There are plenty of tools allow for MITM also for (anony DH) SSL/TLS 
sessions when you can not authenticate the identity of the remote end.. you might have
a confidential session with the intended party or.. an attacker.. :D  In that sense:

   HTTP ~= not authenticated HTTPS.

At least from a trust point of view.. both of them should not be accredited with any
trust... :) And applications should reflect this in how they treat connections in their
UIs. The same would apply for SCP vs FTP..

My last my two cents on this topic (sorry for the off topic) ..

Cheers,
Max

P.S.: If interested reply off-list, please..

P.P.S.: Thanks to the chairs for not yelling at us for this OT... :D

On 07/26/2011 07:37 AM, Yoav Nir wrote:
>>> Max Pala<[email-masked]>  writes:
>>>

-- 

Massimiliano Pala, Ph.D.
Director, OpenCA Labs
Professor, NYU Poly

---

From: Martin Rex <[email-masked]>
Date: Tue, 26 Jul 2011 23:06:03 +0200 (MEST)

Miller, Timothy J. wrote:
> 
> --Apple-Mail-1-518233080
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain;
> 	charset=us-ascii
> 

Definitely.  And it is how TLS worked on the iPhone all the time.  :-D

-Martin

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 27 Jul 2011 07:58:47 -0400

> a confidential session with the intended party or.. an attacker.. :D  In that sense:

OTOH, don't let the perfect be the enemy of the good enough.

-- T

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 27 Jul 2011 08:02:05 -0600

On 07/27/2011 05:58 AM, Miller, Timothy J. wrote:
[..]
> OTOH, don't let the perfect be the enemy of the good enough.

Heheheh... I am always in favor of good enough.. but when it *is* good enough! :D
If the security level we are achieving is the same as the one "implemented"
by the TSA guys at the airport (annoying and practically useless).. I think
we can and should do better than that.. :D

For example, keeping track if a certificate/key (also if untrusted) has changed
over time when connecting to a server could help in mitigating the MITM threat
if the first time you connect you were not already MITM-ed.. but who's really
implementing that (if non-auth connections are permitted) besides.. SSH ? :D

Cheers,

-- 

Massimiliano Pala, Ph.D.
Director, OpenCA Labs
Professor, NYU Poly

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 27 Jul 2011 13:30:43 -0400

On Mon, 2011-07-25 at 16:18 -0600, Max Pala wrote:
> I understand what the browser vendors point of view is. The problem is
> the assumption that to users can give any value to https:// vs
> http:// . Plenty of research demonstrated that that is not true. One
> of the few elements that users can recognize is the lock.. Not the
> protocol identifier.

For users, recognition of the indication is not as good as one would
like.  But web developers and sysadmins will type in https URLs and
expect the system to honor their stipulation.

> After all, encrypting contents to an "unknown" or "unveriifed" party
> is no different

(Let's say "worse" to avoid getting tangled in separate issues.)

> than not encrypting it at all. That's the point. It is still an

That is correct, but that does not mean you can take a https request
where the server authentication failed and just turn off the indicators
or otherwise redirect to a less secure mode, for the reasons I
explained.

> If browser vendors implemented the concept of trusted/not-trusted not
> based on just an "s"

What you literally said has historically been a common misconception,
but Mozilla has fully recovered from it with the removal of the lock in
Firefox 4 (see
https://groups.google.com/group/mozilla.dev.usability/msg/b88a91ee318e0d05 ).

I think what you really intend to complain about here is the regime of
all-or-nothing server authentication.  When it fails, it fails, and that
can be a pain.  But it lends a single (more-or-less) well-defined
meaning to https URLs, which is a powerful abstraction.  The alternative
is to make web developers think about security policy every time they
write a link to a secure site; maybe they should, but in practice that
is a huge burden that we are currently getting by without.

-- 
Matt

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 27 Jul 2011 14:19:30 -0400

> implementing that (if non-auth connections are permitted) besides.. SSH ? :D

Certificate Patrol (Firefox extension).

The Google Certificate Catalog has the data available in DNS TXT records, but I'm not certain who's using it yet.

-- T