Subject: [pkix] Fixing the SSL PKI versus "Usable" Client-side PKI

From: Anders Rundgren <[email-masked]>
Date: Wed, 11 Apr 2012 13:38:34 +0200

Dear All,

It seems that there's no end to the amount of time and energy available for
addressing various short-comings of the SSL PKI.  This is of course very good.

What's a little bit less understandable is why the interest in making client-side PKI
more useful is close to zero.  It is true that there isn't any money to make on the
software and protocols.  However, the availability of usable PKI clients will pay itself
through indirect means (more CAs, more services and less security breaches).

>From a security point of view it is important to realize that even if the SSL PKI or DNS
get corrupted, a client-PKI-based login to "badbank.com" won't give "badbank.com"
any access to "goodbank.com".  Using static passwords (the current "standard"),
all bets are off, not to mention how well shared passwords work...

The current PKI enrollment solutions (maybe with Apple's iPhone scheme as a
notable exception) are close to useless for consumers.

The SSL credential selection GUIs are also based on ideas that only PKI geeks
can possibly appreciate.  Many service providers feel it would be downright
embarrassing offering such a clunky interface to their users.

The majority of issuers of consumer-PKI have therefore developed their own
client-side PKI software which address things like GUI, PINs, X-platform, etc.

IMHO, fixing a little bit here and there in a completely uncoordinated fashion
will never return an interoperable and useful foundation for consumer-PKI.

Comments?

Anders

---

From: Stephen Wilson <[email-masked]>
Date: Thu, 12 Apr 2012 06:01:07 +1000

My comment is that client side certificate management needs fixing as 
much as client side car maintenance.  Why do it?

PKI is the classic case of a technology that appalls in the rough but is 
indispensible when embedded.  My list of successful client side PKI 
deployment includes EMV DDA chip cards, the health cards of Austria, 
Taiwan, Thailand, Malaysia, France and others, the Estonia government 
services card, CAC, PIV and Skype.

See http://lockstep.com.au/blog/2011/01/16/embedded-pki-on-the-cards.html

General purpose, naked, personal digital certificates are of historical 
interest only!  PKI should not be about creating a vertically integrated 
identity certificate management process.  It should be about taking 
existing relationships and instantiating them in special purpose digital 
certificates congruent with those relationships.

See http://lockstep.com.au/library/pki/relationship_certificates.html

Cheers,

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

On 11/04/2012 9:38 PM, Anders Rundgren wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>
>

---

From: Ogle Ron <[email-masked]>
Date: Wed, 11 Apr 2012 16:13:21 -0400

I agree.  Anyone using a Cable Modem and many DSL services are using a PKI
implementation today in the background.  I know that we are heavily
relying upon PKI for our consumer electronics products that are being
produced today.  Of course, you won't see our CA certs in any browser or
OS implementations.

I'd say that there are more certs created and installed in embedded
systems than in use for any other reason.  We don't need or want Name
Constraints to be marked critical to provide security in our PKI.

Ron Ogle

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 12 Apr 2012 07:58:23 +0200

> much as client side car maintenance.  Why do it?

CONDENSED RATIONALE

Currently people login to various services on the Internet; often several times
per day.  In the majority of cases they use a userid/password combination for login.
Quite a bunch of these users (including myself) try to reduce the awkwardness of
this system by reusing passwords at different sites.

When you pay for stuff on the Internet you typically use non-secure(d) credit-card
credentials.

PROPOSAL

A consumer-oriented on-line enrollment system would IMHO be the single most efficient
measure for enabling us to slowly but surely move away from static passwords and payment
systems that were designed in another time and for another purpose.

If somebody has a better suggestion, I encourage you to present it.

-- Anders Rundgren

---

From: Stephen Wilson <[email-masked]>
Date: Thu, 12 Apr 2012 20:13:48 +1000

Anders,

But that's not any sort of PKI challenge is it?  It's even less a PKIX 
specific issue.  Rather you've stated a broad federated identity vision.

And on federated identity, I have to say that the dream of a 
one-size-fits-all identity (or identification/enrolment as you frame it) 
is impractical. Of late I have been thinking and publishing about 
digital identity through an ecological lens.  I have concluded that the 
diversity of identities we see today is a result of natural selection.  
If a single all-purpose identity was beneficial (nett nett), then I 
reckon natural selection would have delivered it already, maybe 
commercially. Especially commercially!  But no, even in countries with 
national identity systems, these things are NOT used universally in 
commerce.  Instead, everywhere in the world has siloed banking 
identities, health IDs, employee IDs, and all manner of customer 
reference numbers.  This is because identification protocols (which are 
just one element in risk management) have to be precisely matched to 
local environmental conditions.  It's the first rule of risk management: 
understand your own business and adopt risk management ploys that are 
suited to your circumstances.  Risk management orthodoxy works against 
universality.  Thus there is no universal identification protocol that 
delivers knowledge of the customer suitable for all conceivable 
applications.

See also
http://lockstep.com.au/library/identity_authentication/an-ecological-theory-of-digit.html 

and
http://lockstep.com.au/blog/federated-identity

Cheers,

Steve Wilson
Lockstep.

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 12 Apr 2012 12:48:19 +0200

> specific issue.  Rather you've stated a broad federated identity vision.

Stephen,
I guess you have interpreted enrollment as some kind of sign-up procedure?

This is of course a part of enrollment on the web but that's the beauty of
the web; you can sign-up for anything.  What's missing (IMO...) is a way to
enroll that instead of providing you with yet another usersid/password
combination, equips you with an X.509 certificate and matching private key.

The universality of issued credentials is completely out-of-scope for
this proposal, anything else would be silly.  If providers believe that
passwords are more suited to their risk management concepts they should
of course continue with passwords.  This proposal is about offering a
useful alternative.

The level of identity verification applied during enrollment is also
out-of-scope since this is fairly technology independent.

I agree that this is not a PKIX issue but that has more to do with IETF
legacy (IETF do not make browser standards) than with the actual question.

Do you think that Facebook should purchase and securely distribute 500 000 000
smart cards in order to improve their login solution?

Anders

---

From: Stephen Wilson <[email-masked]>
Date: Fri, 13 Apr 2012 07:15:47 +1000

I see. Sorry, I did read "enrolment" as meaning sign up. And I thought 
you were talking to the (overstated) issue of multiple credentials.

So I agree with you.  I wish that people got smartcards instead of 
anything else.  And I wish that device manufacturers standardised on 
built-in smartcard readers, as they started to in 2003 after Microsoft 
put smartcard support into their software stack.  a decade later, I can 
see a new wave of smartcard use now that NFC/wifi components can be 
co-opted to read/write contactless smartcards.  In principle it's an 
easy matter for a PIV card to connect to any NFC enabled device.  We 
could get read of the dreaded smartcard reader problem overnight.

Instead of Facebook ... if banks said "the hell with online fraud and ID 
theft, and the hell with craziness like 3D Secure -- let's instead use 
EMV smartcards for Internet payments" ... we would see all those laptop 
and tablet manufacturers rush to reinstate card readers in their 
products.  As an engineering exercise, it's nearly trivial.  The 
decision to prioritise smartcard readers in computers is a product 
marketing question.  We just need a killer app, like payments, to make 
the decision worthwhile.

Cheers,

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

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 13 Apr 2012 06:23:59 +0200

> could get read of the dreaded smartcard reader problem overnight.

My perspective on this is slightly different.  IMO this issue (as well as PKI...)
is essentially "owned" by three major laggards: Governments, Banks, and Microsoft.

Since the first two are numerous as well as geographically and culturally
diverse it would be wrong giving them the blame.  However, since they to
some 90% have relied on a single client-OS vendor, the generally pitiful
state of client-side PKI in consumer PCs is unilaterally due to Microsoft's
limited of understanding of this market.  Over the years I have met quite
a bunch of Microsoft Program Managers and they all say the same thing:
"There is no business case for consumer PKI".  In some way this is also
true since there is no paying customer out there.

Due to that, the banks in the EU that actually use consumer PKI have been
forced developing their own client-side software.  I guess Stefan (PKIX
co-char), never told that to his boss when he worked for Microsoft (in the
US a subordinate typically gets fired if he/she criticizes company strategy).

This has and still is the primary motivation behind my enrollment "crusade".
However, it is also possible that the whole idea reviving traditional PCs is
toast, it is really the mobile devices that are in the center these days.

Here there won't be any EMV cards so you need an on-line enrollment system
to provision virtual (running in embedded security HW), EMV, SIM, PIV etc etc.

The smart card industry is desperately trying to get a piece of the cake:
http://www.globalplatform.org/documents/Consumer_Centric_Model_White_PaperMar2012.pdf

It is essentially Google and Apple that run this show nowadays.  Since they
also have the services, there is an entirely new motivation these days.

Anyway, PKIX won't be there when it actually happens; that's for sure!!!

Cheers,
Anders

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 17 Apr 2012 14:43:18 -0700 (Pacific Daylight Time)

> is essentially "owned" by three major laggards: Governments, Banks, and Microsoft.

This issue is "owned" by ISO, which means that it's on the governments who are participating in ISO.

The most important aspect of any access-control system (especially financial) is auditability, and the ISO standards don't cause enough data to be transmitted to the cryptographic container for the container to write its own audit logs.  PKCS#11 exposes ISO functionality, so it doesn't have a "I'm sending you something that I want you to digest for me" call.  Thus, we have no idea that the digests submitted are being calculated correctly, and no idea what the digests we're signing actually mean.

Instead, we have to implement the auditing service externally, which means that we must be able to trust that we are the sole controllers of the cryptographic containers involved.

> true since there is no paying customer out there.

Ah, Microsoft spreading lies again.

There is no business case for discarding Apache httpd's SSLVerifyClient optional_no_ca, but it's discarded by the technical people because its documentation says that "optional_no_ca is actually against the idea of authentication".  Instead, we end up with applications which handle their own username and password error flows because optional_no_ca is in fact the only way to present a custom error page when people inadvertently try to log in with the wrong certificate or before they've ever been issued a certificate for the service in question.

There is no business case for consumer X.509-as-tied-to-X.500.  There is a business case for enrolling your site's own credentials.  There is a business case for whispering to a friend.  (The problem is that attempts like this to repurpose X.509 are maligned by e.g. Firefox.)

> US a subordinate typically gets fired if he/she criticizes company strategy).

...so why haven't they gotten together to fund the development of a unified interface?  Why haven't they contributed their quantum leaps in client PKI presentation?  How much of the blame likes in their desire to have a proprietary edge?

> toast, it is really the mobile devices that are in the center these days.

I am of the opinion that "enrollment is cheap, verification is expensive."  Once the identity is verified, there's no reason at all to avoid enrolling additional keys and linking them to the same record, as long as you define the enrollment process as more than just the application of a single key per-party.

What's happened to this point is that nobody's bothered to authenticate the keystore on each individual device, so the keystore itself can't assert that it generated the key with knowledge of the policy governing said key generation.  If the enrolling certifier has evidence that the key was generated properly -and- that it was submitted by the principal, it can securely enroll additional keys.

This is not impossible.  It just requires examining things in the "how can I get past this problem?" inventing mindset.

> Anyway, PKIX won't be there when it actually happens; that's for sure!!!

...unless everyone who's terrified of changing anything for fear of Violating The Purity Of The Design Spec is summarily removed from the organization, anyway.  We need to make this work.  It's unacceptable that we give excuses much like "you didn't create this signature under the dark of the moon with the blood of a sacrificed chicken on a ritually sanctified silver dagger washed in the tears of a virgin... so we're just going to interfere with and prevent you from doing the work you need to do."

I mean no offense, but this really needs to be said.  The PKI Priesthood is like the rigid hierarchy of Vatican Catholicism mixed with the "oh God please let this be sufficient to not do what I fear You will" and kosher laws of Orthodox Judaism and the blood sacrifice consecration of Haitian Vodoun all rolled into one horrible blasphemy of rote ritual for all the wrong reasons.  Can't we defrock the PKI Priests?  Or am I stuck in the establishment-questioning shoes of Martin Luther (father of Lutheranism after he denounced Vatican Catholicism as corrupt)?

-Kyle H

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 18 Apr 2012 08:31:30 +0200

Hi Kyle,
I'm not able to respond to your elaborate input because I'm working with a much
more basic question which is "getting away from passwords".  To have a chance of
succeeding you need Vision, Ambition, Marketing, Competence, and Funding.  Maybe
you even need a portion of luck :-)

One of the problems is that if you intend to create something of this kind you
[presumably] need a requirement list.  The naked truth is that getting such a
thing is essentially impossible because the existing users of consumer PKI don't
know which one of the gazillion security standards efforts are for "real", and
therefore do not [actively] support any of them.

A true standardization effort could have a slim chance if it was supported
by NIST since banks and European governments lack the necessary "bandwidth".
However, I have indeed talked to a bunch of NIST people and I believe they
are not particularly interested in consumer authentication in spite of the
fact that this nowadays includes the considerably "hotter" BYOD movement.

Due to this, the fate of consumer PKI firmly resides in the hands of big vendors
which are exclusively targeting mobile devices with embedded security hardware.
The smart card concept never worked well as consumer solution in desktop PCs.

IMO, there is actually a way ahead and that is "putting the cart before the horse"
which means that instead of following the whims of the severely divided smart card
community, you define a standard card and provide a *fixed* driver.  Implementing
a minute set of cryptographic operations is actually not rocket science while
developing and distributing middleware for a huge number of ever-changing platforms
takes forever and still you never know for sure if it is actually working!
By making the driver a *platform vendor issue only*, things get much easier.

PIV was a step in this direction but NIST didn't standardize the management
functions since the card industry wanted to keep something to be unique with.

Anders

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 18 Apr 2012 10:23:04 -0400

From: Kyle Hamilton

> I am of the opinion that "enrollment is cheap, verification
> is expensive."  Once the identity is verified, there's no
> reason at all to avoid enrolling additional keys and linking
> them to the same record, as long as you define the enrollment
> process as more than just the application of a single key per-party.

You'll get no argument from the priesthood on that point, as long as
vocabulary is understood.  To some, "registration" includes both
identity management and credential issuance, while "enrollment" means
assigning privileges to existing identities.  (Common English usage
provides no help - you can either enroll or register once as a college
student, and then register or enroll in multiple courses.)  Identity
management itself is overloaded - in my taxonomy it includes just
management of identifying information about entities and excludes
credential issuance and privilege assignment.  Others include two or all
three of those functions under identity management.  You apparently use
verification to mean identity proofing as part of credential issuance,
others think it means authenticating the source of a request.

> What's happened to this point is that nobody's bothered to
> authenticate the keystore on each individual device, so the
> keystore itself can't assert that it generated the key with
> knowledge of the policy governing said key generation.
> If the enrolling certifier has evidence that the key was
> generated properly -and- that it was submitted by the principal,
> it can securely enroll additional keys.

Which requires management of device identities and issuance of device
credentials, an area of active research.  My employer currently supports
only web servers and domain controllers in its device identity and
credential management system.  As Anders says, mobile devices are here
now, and developing usable ways to use device identities and user
identities to express user privileges is an urgent unmet need.  Device
identities alone are insufficient - my daughter calls home with a
friend's phone more often than she uses her own, and it's a non-starter
to assume that devices will not be borrowed or shared in business
environments.  I never hand someone my badge or drivers license to use,
whereas I have an operational requirement to lend or share my tablet or
smartphone without giving the user access to my credit cards and email
accounts. 

"Verification" (of who's behind an action, regardless of which devices
or keys are used to authenticate a protocol message) is indeed hard.
Key generation and credential issuance are not "easy", but they are
trivial mechanical tasks, unlike properly managing identities and
privileges.

Dave

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 18 Apr 2012 21:33:30 +0200

On 2012-04-18 16:23, Kemp, David P. wrote:

There is indeed a pretty large terminology variation/confusion in this space.

Regarding the mentioned use-case, multiple users for a single device,
I do not see that as the *most* pressing issue to solve.

It is rather a single user having multiple roles that intrigues
me as well as the device vendors.  It is possible that you could
address David's use-case with a "guest" VM that only allows you to
phone and surf.  The problem is really how to switch between these modes
without creating too much fuzz for the true user.

I'm not sure that "device identities" is a universally understood term.
I only use it for a fixed credential that is bolted onto a cryptographic
platform and can attest that platform's brand and serial number.  It is
used for supporting end-to-end-secured enrollment/credential issuance.

One of the things enabled by such a scheme is to use your CAC/PIV/eID
(or AD login) as "bootstrap" for a securely provisioned ID "clone" in
another device using a self-service process.

Eventually the ID clone will surpass its origin in usability, presumably
also supporting physical access control.

Pretty mind-boggling in my opinion!

I expect this platform to be a part of future processors from vendors
like Intel, because the entire caboodle won't take more than 0.1% of
the silicon real estate of a current PC CPU:
http://openkeystore.googlecode.com/svn/trunk/resources/docs/tee-se-combo.pdf

Like all powerful technologies, the concentration of power has unwanted
side-effects when it breaks down.

Anders

---

From: Ben Laurie <[email-masked]>
Date: Wed, 18 Apr 2012 21:18:22 +0100

On Thu, Apr 12, 2012 at 11:48 AM, Anders Rundgren <[email-masked]
> wrote:

http://www.browserauth.net/

---

From: Ogle Ron <[email-masked]>
Date: Wed, 18 Apr 2012 16:33:27 -0400

We are going through similar problems but with consumer electronics
products instead of the typical PC/iphone/ipad device.  During
manufacturing, we are installing a "device" certificate that uniquely
identifies that device to the world.  We can then use that device ID to
impart other functions/features.

Again like your situation, we are working on imparting additional Ids into
the device that can define users and/or services that device is allowed to
use.  An interesting part to this is that these Ids can only be as trusted
as the device itself allows.  So in this case, the issuer of these
additional Ids along with any RP has to not only understand the ID but
also the device it originated.

For example, you can have a cable modem that doesn't do much protection.
Any additional ID that it uses would be of low assurance. However a set
top box that is more expensive and has dedicated crypto functions can
provide protections of the credentials at a very high level.

This situation may be telling by using OIDs in these additional ID certs,
but it is very difficult to provide inter-operable designs that way.
Maybe a better solution would be to extend TLS to allow for multiple
client-side Ids to be provided during authentication.

To give the military folks an idea on this, I'll provide an example.  As
you may have noticed, the newer TV systems are incorporating some basic PC
functionality using the network.  So now you want to do some on-line
shopping at the PX or you want to look at your medical or something else
that requires CAC access.  You plug in your USB card reader to the TV and
insert your CAC card and provide your PIN.  The TV browser recognizes the
CAC card and uses if for authentication.  No problems.

Now what if instead of using the CAC card all of the time, the CAC card
was just used to download another temporary cert that is originated from
the TV itself or maybe hanging out there in the cloud but could be
retrieved by the TV to be used by you.  This is where I think things are
going and makes PKI usable from the client side.  It all becomes part of
those background processes like DNS.  So now you can do what you did
before, but you don't necessarily have to have a CAC with you all of the
time.

Of course, now the problem becomes how can we trust the TV.  For regular
folks, we don't have a CAC card, but we need to do the same thing as I
described above.

Anyway, isn't it interesting to see how the PC world and consumer
electronics world is becoming one.

My .02
Ron Ogle

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 18 Apr 2012 16:52:36 -0700 (Pacific Daylight Time)

Anders,

I am entirely with you on "getting away from passwords".  Though, instead of wringing my hands about it and thinking that I can't do anything for it, I'm creating the system that I perceive the need for.  I despise passwords, and I believe that they should have been done away with 15 years ago, the moment the Wassennar Arrangement was inked in 1998.

There exist a couple of barriers which prevent passwords from going extinct.  There are two that I have my eyes on.  One exists at Mozilla, the other at Apache httpd.

> you even need a portion of luck :-)

My vision: I believe that every individual in the world has the absolute right to keep his own secrets.  Every person in the world has the right to be safe from impersonation fraud.  Every person in the world has the right to form his own associations, and to create systems to help those associations work as expected by the participants.  What has prevented it to this point is the lack of a useful, comprehensible interface.  The Clerk of Courts exemplifies everything that we expect from our information systems, and should be the role model we try to emulate.
Ambition: I'm going to make sure that everyone has the capacity to keep his own secrets, with an interface much like the Clerk of Courts presents to the Judges of the Courts, meaning nearly invisible but providing exactly what information/paperwork is needed at any given moment.
Competence: I juggle cryptographic building blocks until every need is met.  At this point, I'm looking for people to evaluate the design I created to make passwords the wave of the past.  You seem to be interested enough in the topic and competent enough in the field to be able to give feedback.
Marketing/Funding: I'll hand it to Mozilla and/or Apache.
Luck: that nobody else has yet done it right. :-)

I'm working to improve Mozilla's platform so that sites can create and enroll their own credentials without throwing away the benefits of its root program.  (The bug: locally-trusted certificates present the same UI as root program certificates.)

I'm also working to remove Apache mod_ssl technical documentation about SSLVerifyClient, which dismisses the capacity to present a custom credential error recovery flow as not "interesting" (i.e., optional_no_ca).

The system I think we need: a workflow implementation system for the end-user with predesigned workflows for almost everything that one would want to do with cryptography and information storage, providing a kind of secure bundling of associated information and presenting the kind of "this is what you need at this moment" service that the Clerk provides to the Judge.

> therefore do not [actively] support any of them.

Which is why I've created my own Requirements.  I'm sure the rest of the world will catch up eventually:
1) Assert multiple credential chains from multiple credential sources atomically, in verifiable form.
2) Assert non-verifiable data in the same atom.
3) Provide an optional means to encrypt that credential chain atom to the intended recipient.
4) Provide a means to ensure that even if the digests used for the signatures are compromised, the data can still be known good.
5) Provide stapled OCSP responses or the current CRL for every certificate in every credential chain.
6) Provide a timestamp, so that the time of signature can be shown to exist within the validity periods of the certificate chains' OCSP.
7) Include every device the user has that can understand the protocol, including PCs, notebooks, tablets, phones, and credential stores.
8) Reuse as much crypto, standard and code as possible, subject to the constraints 1-8.  If possible, use areas of the standards that have been disclaimed by the standards bodies themselves (such as self-signed X.509 structures as something other than a trust anchor container).
9) Present authorization UI on one or more devices other than the credential store and the device which submitted the signature request, to reduce the opportunity for malware on the main interface to apply an unauthorized signature.
10) Save -everything- that has ever been signed.

Might you be interested in a data format which enables these to be met, without changes to the existing CA infrastructure, without any changes to any technical standards including TLS and S/MIME, and without worrying about the lack of motion in standards bodies?  Standards come about because something works, not because people think that it will work if they're built to.  This is the failure of PKIX-WG.

> Due to this, the fate of consumer PKI firmly resides in the hands of big vendors

This is perhaps incorrect.  The fate of consumer PKI in US appears to reside in my hands, as I seem to be the only person in US who thinks that there does exist a business case for it.

If you want something cryptographic done, you pretty much have to roll your own because the current standards are so distressingly ignorant of reality. :(

> The smart card concept never worked well as consumer solution in desktop PCs.

Agreed.  I have a laptop with a smart card reader.  It is much more hassle than it's worth.

> By making the driver a *platform vendor issue only*, things get much easier.

I don't actually think this is the way ahead.  The way ahead is to make it work, and then let other people into the game.

The problem is partially PKCS#11, but much more globally ISO/IEC 7816-*.

For auditability I want to ensure that I have absolute control over the container and its auditing at all times, and that is impossible with a smart card (or any PKCS11 module) that doesn't have a custom enclosure.

> functions since the card industry wanted to keep something to be unique with.

NIST is part of the problem, publishing only half-baked semistandards.  But, I don't think the actual problem preventing consumer PKI from taking root is NIST.  The fact that smart cards exist (and the vendors are allowed to continue pushing and enforcing their proprietary extensions) is itself The Problem.  Smart cards are the wrong technology, mostly because of the proprietary vendor lock-in that these semi-standards have created.

So, I'm more than happy to not only "ignore the smart card industry's desires", but "ignore the smart card industry's existence".

The Raspberry Pi (http://www.raspberrypi.org/) is an open device with an 800MHz processor and a $25 price tag.  This is the credential storage device of the future, low-level enough that I can take complete control as I need to, fast enough that it can perform acceptably.  With IPv6, everyone on earth could have ten of them and there would still be more than 3.40E+38 (340+ short-scale undecillion) addresses left, subject to the lossage of network versus interface addressing.

Mixing this with a smartphone means that you suddenly have a remote keystore that you can send unsigned requests and signed authorities to, via a UI device you've already got in your pocket.

I seem to be the only security-minded person in US who thinks that IPv6 utility is not only awesomesauce but the only way forward, because we currently cannot use our cryptographic keys as our IP addresses.  But, we can enable that if we use them as portions of multicast addresses.  (physical location is personal information and must be protected.)

I also appear to be the only person in US who thinks that every asymmetric key (with few enough exceptions that this is a good general rule) is nonexportably bound to hardware, and hardware dies, so we shall lose every private key we care about.  We must plan for that eventuality while still providing adequate security for our clients.  

I've got a design for this that works on paper, and I'm working to make it reality.

Cheers!

-Kyle H

---

From: Stephen Wilson <[email-masked]>
Date: Thu, 19 Apr 2012 12:49:48 +1000

Just quickly, would you care to clarify what it means to get rid of 
passwords?

Do you really mean single factor authentication (i.e. passwords on the 
own)?

Do you imagine PKI based cards / devices would still be password activated?

Do you really mean reduce the number of passwords?

Do you advocate radical SSO, so that once logged in, you stay logged in 
across arbitrarily many services without ever reentering a password?

I won't apologise for nitpicking, because there's too much woolly 
language in the identity space.  We see maniacal media reports about 
NSTIC doing away with passwords altogether.  And what about the common 
perception that biometrics will do away with passwords? Then along comes 
this palm scanning ATM where that's not only false, but it even requires 
an additional secret over and above the PIN? 
http://news.discovery.com/tech/scan-hand-atm-cash-120414.html

So let's be sure we set the right expectations!

Cheers,

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

On 19/04/2012 9:52 AM, Kyle Hamilton wrote:
> Anders,
>
> I am entirely with you on "getting away from passwords".  Though, 
> instead of wringing my hands about it and thinking that I can't do 
> anything for it, I'm creating the system that I perceive the need 
> for.  I despise passwords, and I believe that they should have been 
> done away with 15 years ago, the moment the Wassennar Arrangement was 
> inked in 1998.
>
> There exist a couple of barriers which prevent passwords from going 
> extinct.  There are two that I have my eyes on.  One exists at 
> Mozilla, the other at Apache httpd.
>
> My vision: I believe that every individual in the world has the 
> absolute right to keep his own secrets.  Every person in the world has 
> the right to be safe from impersonation fraud.  Every person in the 
> world has the right to form his own associations, and to create 
> systems to help those associations work as expected by the 
> participants.  What has prevented it to this point is the lack of a 
> useful, comprehensible interface.  The Clerk of Courts exemplifies 
> everything that we expect from our information systems, and should be 
> the role model we try to emulate.
> Ambition: I'm going to make sure that everyone has the capacity to 
> keep his own secrets, with an interface much like the Clerk of Courts 
> presents to the Judges of the Courts, meaning nearly invisible but 
> providing exactly what information/paperwork is needed at any given 
> moment.
> Competence: I juggle cryptographic building blocks until every need is 
> met.  At this point, I'm looking for people to evaluate the design I 
> created to make passwords the wave of the past.  You seem to be 
> interested enough in the topic and competent enough in the field to be 
> able to give feedback.
> I'm working to improve Mozilla's platform so that sites can create and 
> enroll their own credentials without throwing away the benefits of its 
> root program.  (The bug: locally-trusted certificates present the same 
> UI as root program certificates.)
>
> I'm also working to remove Apache mod_ssl technical documentation 
> about SSLVerifyClient, which dismisses the capacity to present a 
> custom credential error recovery flow as not "interesting" (i.e., 
> optional_no_ca).
>
> The system I think we need: a workflow implementation system for the 
> end-user with predesigned workflows for almost everything that one 
> would want to do with cryptography and information storage, providing 
> a kind of secure bundling of associated information and presenting the 
> kind of "this is what you need at this moment" service that the Clerk 
> provides to the Judge.
>
> 4) Provide a means to ensure that even if the digests used for the 
> signatures are compromised, the data can still be known good.
> 6) Provide a timestamp, so that the time of signature can be shown to 
> exist within the validity periods of the certificate chains' OCSP.
> 7) Include every device the user has that can understand the protocol, 
> including PCs, notebooks, tablets, phones, and credential stores.
> 8) Reuse as much crypto, standard and code as possible, subject to the 
> constraints 1-8.  If possible, use areas of the standards that have 
> been disclaimed by the standards bodies themselves (such as 
> self-signed X.509 structures as something other than a trust anchor 
> container).
> 9) Present authorization UI on one or more devices other than the 
> credential store and the device which submitted the signature request, 
> to reduce the opportunity for malware on the main interface to apply 
> an unauthorized signature.
> Might you be interested in a data format which enables these to be 
> met, without changes to the existing CA infrastructure, without any 
> changes to any technical standards including TLS and S/MIME, and 
> without worrying about the lack of motion in standards bodies?  
> Standards come about because something works, not because people think 
> that it will work if they're built to.  This is the failure of PKIX-WG.
>
> This is perhaps incorrect.  The fate of consumer PKI in US appears to 
> reside in my hands, as I seem to be the only person in US who thinks 
> that there does exist a business case for it.
>
> If you want something cryptographic done, you pretty much have to roll 
> your own because the current standards are so distressingly ignorant 
> of reality. :(
>
> I don't actually think this is the way ahead.  The way ahead is to 
> make it work, and then let other people into the game.
>
> For auditability I want to ensure that I have absolute control over 
> the container and its auditing at all times, and that is impossible 
> with a smart card (or any PKCS11 module) that doesn't have a custom 
> enclosure.
>
> NIST is part of the problem, publishing only half-baked 
> semistandards.  But, I don't think the actual problem preventing 
> consumer PKI from taking root is NIST.  The fact that smart cards 
> exist (and the vendors are allowed to continue pushing and enforcing 
> their proprietary extensions) is itself The Problem.  Smart cards are 
> the wrong technology, mostly because of the proprietary vendor lock-in 
> that these semi-standards have created.
>
> So, I'm more than happy to not only "ignore the smart card industry's 
> desires", but "ignore the smart card industry's existence".
>
> The Raspberry Pi (http://www.raspberrypi.org/) is an open device with 
> an 800MHz processor and a $25 price tag.  This is the credential 
> storage device of the future, low-level enough that I can take 
> complete control as I need to, fast enough that it can perform 
> acceptably.  With IPv6, everyone on earth could have ten of them and 
> there would still be more than 3.40E+38 (340+ short-scale undecillion) 
> addresses left, subject to the lossage of network versus interface 
> addressing.
>
> Mixing this with a smartphone means that you suddenly have a remote 
> keystore that you can send unsigned requests and signed authorities 
> to, via a UI device you've already got in your pocket.
>
> I seem to be the only security-minded person in US who thinks that 
> IPv6 utility is not only awesomesauce but the only way forward, 
> because we currently cannot use our cryptographic keys as our IP 
> addresses.  But, we can enable that if we use them as portions of 
> multicast addresses.  (physical location is personal information and 
> must be protected.)
>
> I also appear to be the only person in US who thinks that every 
> asymmetric key (with few enough exceptions that this is a good general 
> rule) is nonexportably bound to hardware, and hardware dies, so we 
> shall lose every private key we care about.  We must plan for that 
> eventuality while still providing adequate security for our clients.
>>> This issue is "owned" by ISO, which means that it's on the 
>>> governments who are participating in ISO.
>>>
>>> The most important aspect of any access-control system (especially 
>>> financial) is auditability, and the ISO standards don't cause enough 
>>> data to be transmitted to the cryptographic container for the 
>>> container to write its own audit logs.  PKCS#11 exposes ISO 
>>> functionality, so it doesn't have a "I'm sending you something that 
>>> I want you to digest for me" call.  Thus, we have no idea that the 
>>> digests submitted are being calculated correctly, and no idea what 
>>> the digests we're signing actually mean.
>>>
>>> Instead, we have to implement the auditing service externally, which 
>>> means that we must be able to trust that we are the sole controllers 
>>> of the cryptographic containers involved.
>>>
>>> There is no business case for discarding Apache httpd's 
>>> SSLVerifyClient optional_no_ca, but it's discarded by the technical 
>>> people because its documentation says that "optional_no_ca is 
>>> actually against the idea of authentication".  Instead, we end up 
>>> with applications which handle their own username and password error 
>>> flows because optional_no_ca is in fact the only way to present a 
>>> custom error page when people inadvertently try to log in with the 
>>> wrong certificate or before they've ever been issued a certificate 
>>> for the service in question.
>>>
>>> There is no business case for consumer X.509-as-tied-to-X.500. 
>>>  There is a business case for enrolling your site's own credentials. 
>>>  There is a business case for whispering to a friend.  (The problem 
>>> is that attempts like this to repurpose X.509 are maligned by e.g. 
>>> Firefox.)
>>>
>>> ...so why haven't they gotten together to fund the development of a 
>>> unified interface?  Why haven't they contributed their quantum leaps 
>>> in client PKI presentation?  How much of the blame likes in their 
>>> desire to have a proprietary edge?
>>>
>>> I am of the opinion that "enrollment is cheap, verification is 
>>> expensive."  Once the identity is verified, there's no reason at all 
>>> to avoid enrolling additional keys and linking them to the same 
>>> record, as long as you define the enrollment process as more than 
>>> just the application of a single key per-party.
>>>
>>> authenticate the keystore on each individual device, so the keystore 
>>> itself can't assert that it generated the key with knowledge of the 
>>> policy governing said key generation.  If the enrolling certifier 
>>> has evidence that the key was generated properly -and- that it was 
>>> submitted by the principal, it can securely enroll additional keys.
>>>
>>> This is not impossible.  It just requires examining things in the 
>>> "how can I get past this problem?" inventing mindset.
>>>
>>> ...unless everyone who's terrified of changing anything for fear of 
>>> Violating The Purity Of The Design Spec is summarily removed from 
>>> the organization, anyway.  We need to make this work.  It's 
>>> unacceptable that we give excuses much like "you didn't create this 
>>> signature under the dark of the moon with the blood of a sacrificed 
>>> chicken on a ritually sanctified silver dagger washed in the tears 
>>> of a virgin... so we're just going to interfere with and prevent you 
>>> from doing the work you need to do."
>>>
>>> I mean no offense, but this really needs to be said.  The PKI 
>>> Priesthood is like the rigid hierarchy of Vatican Catholicism mixed 
>>> with the "oh God please let this be sufficient to not do what I fear 
>>> You will" and kosher laws of Orthodox Judaism and the blood 
>>> sacrifice consecration of Haitian Vodoun all rolled into one 
>>> horrible blasphemy of rote ritual for all the wrong reasons.  Can't 
>>> we defrock the PKI Priests?  Or am I stuck in the 
>>> establishment-questioning shoes of Martin Luther (father of 
>>> Lutheranism after he denounced Vatican Catholicism as corrupt)?
>>>
>>> -Kyle H
>>
>

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Apr 2012 05:33:41 +0200 (MEST)

> Just quickly, would you care to clarify what it means to get rid of 

Passwords will be vulnerable and subject to social engineering
as long as users can not reliable recognize authorized password prompts.
The only reliable solution is to restrict passwords exclusively
to trustworthy (=personally owned) hardware.

All other authentication should be restricted to replay&MITM-safe
strong crypto protocols between the trustworthy (=personally owned)
hardware.

> http://news.discovery.com/tech/scan-hand-atm-cash-120414.html

That is an exceptionally stupid idea.

You can not change your biometrics, therefore you MUST NOT reveal
any of your biometrics that might enable someone else to impersonate
you to untrustworthy hardware.

An ATM is unconditionally untrustworthy hardware
(unless it is YOUR OWN ATM and locket up in a safe which only
 you yourself can open, but that is pointless -- simply using
 the safe directly would be much less cumbersome).

-Martin

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 18 Apr 2012 20:43:20 -0700 (Pacific Daylight Time)

Hi Steve,

I wholeheartedly agree with you on the wooly fuzzy language.  So, I'll try to be concise:

I wish to eradicate account names and passwords, the 1-factor authentication that nearly every website on the Internet still uses.  There have been many attempts (including Flash-based persistent browser objects) to create a 2nd factor so that authorized systems don't have to go through the more annoying authentication system which is generally used to authorize the system.  I agree with Martin Rex's reply as well -- passwords are only appropriate for use in the user's own realm of authentication to his devices.

I agree with the idea of authorizing and authenticating the system, by the way, for a particular reason: if every independent keystore has its own keypairs for its own management, it's possible to enroll additional keys in a manner which lets any recognized compromise cause a global revocation of every key certified as being within that keystore.  This is a paramount exposure-limiting necessity.

I would prefer that PKI based devices used some combination of factors rather than some "knowledge", but I'll be quite happy to let users have the capacity to figure out what kind of key protection they need for various things.  "knowledge" is something that's far too easy to compromise, in both the "no, really, I don't remember" and "someone else knows this too" manners.

I do not consider my vision to really be any kind of SSO environment, though.  We know that nearly every user has multiple devices.  Why aren't we using this knowledge to securely send a signature request out to an agent on the user's phone, and then receive an authorizing signature from a key held on that device before applying the main one?  (For bonus points, create a switch on the user device which puts it either into "security authority" mode or "applications" mode, and cause an incoming signature request to say "hey, hit this switch, something wants your authority" over the applications.)

In the end analysis, I would prefer to let every individual service be opted into SSO treatment by the user, according to that user's willingness to accept exposure and liability for its potential misuse.  (We do already have this kind of situation with password managers like the one built into Firefox, and there are pluses and minuses to it.  My main concern is that currently, every use of a key is a high-security ritual that's painful and awkward, no matter how inane the actual utility.  I think I'd be quite happy, for example, to allow my computer to stay logged in to slashdot, in such a way that I don't have to worry about the key being in an ultra tight security authorization environment and having to wrack my brain or rely on muscle memory to key in a password.  I certainly would not be okay with my bank credentials being handled in that manner.)

The web and world are already insecure.  Why would the addition of a cryptographic layer necessarily make that any less the case?

-Kyle H

On Wed, Apr 18, 2012 at 7:49 PM, Stephen Wilson <[email-masked]> wrote:
> Do you really mean single factor authentication (i.e. passwords on the own)?
>
> I won't apologise for nitpicking, because there's too much woolly language
> in the identity space.  We see maniacal media reports about NSTIC doing away
> with passwords altogether.  And what about the common perception that
> biometrics will do away with passwords? Then along comes this palm scanning
> ATM where that's not only false, but it even requires an additional secret
> over and above the PIN?
>> I am entirely with you on "getting away from passwords".  Though, instead
>> of wringing my hands about it and thinking that I can't do anything for it,
>> I'm creating the system that I perceive the need for.  I despise passwords,
>> and I believe that they should have been done away with 15 years ago, the
>> moment the Wassennar Arrangement was inked in 1998.
>>
>> extinct.  There are two that I have my eyes on.  One exists at Mozilla, the
>> other at Apache httpd.
>>
>> My vision: I believe that every individual in the world has the absolute
>> right to keep his own secrets.  Every person in the world has the right to
>> be safe from impersonation fraud.  Every person in the world has the right
>> to form his own associations, and to create systems to help those
>> associations work as expected by the participants.  What has prevented it to
>> this point is the lack of a useful, comprehensible interface.  The Clerk of
>> Courts exemplifies everything that we expect from our information systems,
>> and should be the role model we try to emulate.
>> Ambition: I'm going to make sure that everyone has the capacity to keep
>> his own secrets, with an interface much like the Clerk of Courts presents to
>> the Judges of the Courts, meaning nearly invisible but providing exactly
>> what information/paperwork is needed at any given moment.
>> met.  At this point, I'm looking for people to evaluate the design I created
>> to make passwords the wave of the past.  You seem to be interested enough in
>> the topic and competent enough in the field to be able to give feedback.
>> enroll their own credentials without throwing away the benefits of its root
>> program.  (The bug: locally-trusted certificates present the same UI as root
>> program certificates.)
>>
>> I'm also working to remove Apache mod_ssl technical documentation about
>> SSLVerifyClient, which dismisses the capacity to present a custom credential
>> error recovery flow as not "interesting" (i.e., optional_no_ca).
>>
>> end-user with predesigned workflows for almost everything that one would
>> want to do with cryptography and information storage, providing a kind of
>> secure bundling of associated information and presenting the kind of "this
>> is what you need at this moment" service that the Clerk provides to the
>> Judge.
>>
>> constraints 1-8.  If possible, use areas of the standards that have been
>> disclaimed by the standards bodies themselves (such as self-signed X.509
>> structures as something other than a trust anchor container).
>> credential store and the device which submitted the signature request, to
>> reduce the opportunity for malware on the main interface to apply an
>> unauthorized signature.
>> Might you be interested in a data format which enables these to be met,
>> without changes to the existing CA infrastructure, without any changes to
>> any technical standards including TLS and S/MIME, and without worrying about
>> the lack of motion in standards bodies?  Standards come about because
>> something works, not because people think that it will work if they're built
>> to.  This is the failure of PKIX-WG.
>>
>> reside in my hands, as I seem to be the only person in US who thinks that
>> there does exist a business case for it.
>>
>> your own because the current standards are so distressingly ignorant of
>> reality. :(
>>
>> I don't actually think this is the way ahead.  The way ahead is to make it
>> work, and then let other people into the game.
>>
>> For auditability I want to ensure that I have absolute control over the
>> container and its auditing at all times, and that is impossible with a smart
>> card (or any PKCS11 module) that doesn't have a custom enclosure.
>>
>> NIST is part of the problem, publishing only half-baked semistandards.
>>  But, I don't think the actual problem preventing consumer PKI from taking
>> root is NIST.  The fact that smart cards exist (and the vendors are allowed
>> to continue pushing and enforcing their proprietary extensions) is itself
>> The Problem.  Smart cards are the wrong technology, mostly because of the
>> proprietary vendor lock-in that these semi-standards have created.
>>
>> The Raspberry Pi (http://www.raspberrypi.org/) is an open device with an
>> 800MHz processor and a $25 price tag.  This is the credential storage device
>> of the future, low-level enough that I can take complete control as I need
>> to, fast enough that it can perform acceptably.  With IPv6, everyone on
>> earth could have ten of them and there would still be more than 3.40E+38
>> (340+ short-scale undecillion) addresses left, subject to the lossage of
>> network versus interface addressing.
>>
>> keystore that you can send unsigned requests and signed authorities to, via
>> a UI device you've already got in your pocket.
>>
>> I seem to be the only security-minded person in US who thinks that IPv6
>> utility is not only awesomesauce but the only way forward, because we
>> currently cannot use our cryptographic keys as our IP addresses.  But, we
>> can enable that if we use them as portions of multicast addresses.
>>  (physical location is personal information and must be protected.)
>>
>> I also appear to be the only person in US who thinks that every asymmetric
>> key (with few enough exceptions that this is a good general rule) is
>> nonexportably bound to hardware, and hardware dies, so we shall lose every
>> private key we care about.  We must plan for that eventuality while still
>> providing adequate security for our clients.
>>>> financial) is auditability, and the ISO standards don't cause enough data to
>>>> be transmitted to the cryptographic container for the container to write its
>>>> own audit logs.  PKCS#11 exposes ISO functionality, so it doesn't have a
>>>> "I'm sending you something that I want you to digest for me" call.  Thus, we
>>>> have no idea that the digests submitted are being calculated correctly, and
>>>> no idea what the digests we're signing actually mean.
>>>>
>>>> means that we must be able to trust that we are the sole controllers of the
>>>> cryptographic containers involved.
>>>>
>>>> There is no business case for discarding Apache httpd's SSLVerifyClient
>>>> optional_no_ca, but it's discarded by the technical people because its
>>>> documentation says that "optional_no_ca is actually against the idea of
>>>> authentication".  Instead, we end up with applications which handle their
>>>> own username and password error flows because optional_no_ca is in fact the
>>>> only way to present a custom error page when people inadvertently try to log
>>>> in with the wrong certificate or before they've ever been issued a
>>>> certificate for the service in question.
>>>>
>>>> There is no business case for consumer X.509-as-tied-to-X.500.  There is
>>>> a business case for enrolling your site's own credentials.  There is a
>>>> business case for whispering to a friend.  (The problem is that attempts
>>>> like this to repurpose X.509 are maligned by e.g. Firefox.)
>>>>
>>>> unified interface?  Why haven't they contributed their quantum leaps in
>>>> client PKI presentation?  How much of the blame likes in their desire to
>>>> have a proprietary edge?
>>>>
>>>> expensive."  Once the identity is verified, there's no reason at all to
>>>> avoid enrolling additional keys and linking them to the same record, as long
>>>> as you define the enrollment process as more than just the application of a
>>>> single key per-party.
>>>>
>>>> What's happened to this point is that nobody's bothered to authenticate
>>>> the keystore on each individual device, so the keystore itself can't assert
>>>> that it generated the key with knowledge of the policy governing said key
>>>> generation.  If the enrolling certifier has evidence that the key was
>>>> generated properly -and- that it was submitted by the principal, it can
>>>> securely enroll additional keys.
>>>>
>>>> This is not impossible.  It just requires examining things in the "how
>>>> can I get past this problem?" inventing mindset.
>>>>
>>>> Violating The Purity Of The Design Spec is summarily removed from the
>>>> organization, anyway.  We need to make this work.  It's unacceptable that we
>>>> give excuses much like "you didn't create this signature under the dark of
>>>> the moon with the blood of a sacrificed chicken on a ritually sanctified
>>>> silver dagger washed in the tears of a virgin... so we're just going to
>>>> interfere with and prevent you from doing the work you need to do."
>>>>
>>>> I mean no offense, but this really needs to be said.  The PKI Priesthood
>>>> is like the rigid hierarchy of Vatican Catholicism mixed with the "oh God
>>>> please let this be sufficient to not do what I fear You will" and kosher
>>>> laws of Orthodox Judaism and the blood sacrifice consecration of Haitian
>>>> Vodoun all rolled into one horrible blasphemy of rote ritual for all the
>>>> wrong reasons.  Can't we defrock the PKI Priests?  Or am I stuck in the
>>>> establishment-questioning shoes of Martin Luther (father of Lutheranism
>>>> after he denounced Vatican Catholicism as corrupt)?
>>>>
>>>> -Kyle H
>>>
>>>
>>
>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 19 Apr 2012 12:37:34 +0200

> So let's be sure we set the right expectations!

Stephen, I hate to say it but my answer is a clear "Yes" to all your questions.

That is, I don't advocate SSO or one credential/RP, I'm working with
schemes that are intended to give the market a chance to mix and match
as much as it wants between different identity models as well as with
policy choices.  In fact, even old champ OTP is a part of the plot.

Regarding "radical SSO", I guess the link Ben Laurie posted the other
day is about as far as you can possibly go:

  http://www.browserauth.net

I'm personally more into another Google thingie, the Wallet.

Yes, it is indeed Google that is running the show these days!

Anders