Subject: Re: [pkix] NSTIC - National Strategy for Trusted Identities in Cyberspace

From: Anders Rundgren <[email-masked]>
Date: Wed, 01 Sep 2010 09:57:00 +0200

Kemp, David P. wrote:
> One comment …
> 
>  
> 
> *From:* Stephen Wilson
> 
>>  We wasted untold time and money striving to reduce the
>>  number of certificates people carry (some still dream of just one),
>>  through initiatives like Bridge CAs.  Why spend billions of dollars
>>  to show that a certificate issued in one domain can be recognized
>>  in another, when you could just as well carry on with two certificates?

> How can you “just as well” carry on with two certificates if you don’t 
> deal with trust?

There are different ways to achieve trust.  Bridges represent the the
TTP model taken to its extreme.

> The bridge motive isn’t to reduce the number of certificates people 
> carry, it is to reduce the number of certificates issuers have to manage 
> for “foreign” subscribers.  If you are a Boeing employee with a Boeing 
> cert, why should Northrup have to learn who you are and issue you 
> another certificate just to access Northrup resources?   And why should 
> Lockheed, and DoD, and RundgrenCellularInc CAs and a hundred others all 
> have to do the same?

An alternative to CertiPath and similar awkward stuff the DoD force
on their suppliers would be to use federation between the parties at
the organization level.  This is a light-weight system that also supports
authorization issues, something the bride doesn't do.  I.e. just because
you lost your right to deal with an external party, your cert doesn't have
to be revoked.

Federation is also the foundation for payment networks, i.e. transactions
are (usually) not signed by bank personnel, but by the transaction system.

> The bridge business process has to exist in some form, whether it is run 
> by industry-specific consortia or by independent rating agencies. The 
> problem with the current Bridge implementation is that they expose all 
> their internal garbage to applications, who then have to deal with it at 
> runtime during path development and validation.  The bridge of the 
> future should list ratings and evaluations and CA certificates in a big 
> (virtual) book like Value Line ™, and every relying party domain could 
> pick and choose which CAs to issue cross-certs to.  (If you don’t like 
> the word “trust”, then substitute “enter into a relationship with”). 
>   Every relying party application would then have to deal only with 
> short (2-4 level) certification paths: [root, cross-cert,] CA, and EE.

Have you read the following document?

http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/B2B-article.pdf
"BCA Economics 101: How the BCA enables B2B E-commerce"

This vision has not materialized because it incompatible with how the commercial
world is operating.  Federation is faster. cheaper and much easier to adapt to
different scenarios.  Statically issued certificates for *external usage* doesn't
match the dynamics of today, IMHO not even that of a functioning public sector.

Anders
http://webpki.org/papers/PKI/gateway.pdf

---

From: Patrick Patterson <[email-masked]>
Date: Wed, 1 Sep 2010 13:07:23 -0400

Hi Anders:

> are (usually) not signed by bank personnel, but by the transaction system.

Actually, CertiPath is just the first step in a much longer process to facilitate collaboration within the Aerospace and Defense communities. As PKI is MUCH more mature, and many of the bare bones of Federation rely on things like PKI signed assertions and TLS protected web communications, it was the most obvious first step to take.

CertiPath came about out of the work of the TSCP (www.tscp.org), which is currently working on building on the trust framework that was enabled through the use of the CertiPath bridge to start along the road to Federation. And I would respectfully submit that, at least within the areas of interest of the Aerospace and Defense communities, Federation is NOT necessarily lightweight - in fact, it has been MUCH easier to negotiate the Certificate Policy framework, and get it recognised and agreed to by 10 or so very large companies and 3 Governments, than it is proving to be to get all of the niggly bits of Federation agreed to.

Federation and PKI are two of the pillars upon which future interactions are going to happen in A&D, but you can't really have Federation without the common credentialing regime/framework that the PKI provides.

And besides, there are use cases (such as Email, Aircraft Identification, code/data signing) that Federation just isn't really all that applicable to.

Have fun!

---
Patrick Patterson
President and Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca

tel: +1 514 485 0789
mobile: +1 514 994 8699
fax: +1 450 424 9559

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 1 Sep 2010 13:09:52 -0400

I don't know what you mean by Federation.  To me it means a consortium
of user domains, each of which provides authentication credentials to
its users, and each of which agree to accept credentials from other
domains.  That is what the Certipath bridge is today, that is what a
dynamically-managed flat list of directly trusted CAs might be, and that
is what dynamically-issued-per-transaction authentication assertions
are.

So saying "federation is faster" means nothing to me -- faster than
what?

I don't agree that a model that requires interaction with an "identity
provider" for every transaction is the wave of the future - for one
thing, it would have to be as massively robust as the DNS root servers,
and for another I might not want my identity provider to know which porn
sites I'm looking at :-).  

We used KDCs to distribute keys for every secure telephone call 25 years
ago - that model disappeared when we got public key certificates, and
it's not coming back for applications where the interests of the
transport providers may differ from those of the communicating parties.

Dave

-----Original Message-----
From: Anders Rundgren

http://csrc.nist.gov/groups/ST/crypto_apps_infra/documents/B2B-article.p
df
"BCA Economics 101: How the BCA enables B2B E-commerce"

This vision has not materialized because it incompatible with how the
commercial
world is operating.  Federation is faster. cheaper and much easier to
adapt to
different scenarios.  Statically issued certificates for *external
usage* doesn't
match the dynamics of today, IMHO not even that of a functioning public
sector.

Anders

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 07 Sep 2010 17:43:57 +0200

This should be:

"I have a hard time with the USG certifying Peter to tell John to trust Paul
says Bob while he logs on to his internet bank using an ID and a password to
Eve's phishing server."

What I lack about this discussions about different authentication techniques
and NSTIC is that from what I read they are really just looking into
building an identity federations where different authentication technologies
can be used in a common infrastructure.

<snip>
"To achieve these ideals, identity solutions should be scalable across
multiple federations, spanning traditional geographic borders. An identity
federation allows an organization to accept and trust external users
authenticated by a third party. Within the Identity Ecosystem, individuals
will have the capability to conduct online transactions seamlessly across
numerous service providers and identity federations. Identity solutions
achieve scalability when all participants in the various federations agree
upon a common set of standards, requirements, and enforcement mechanisms for
securely exchanging digital identity information, resulting in
authentication across federations."
<snip>

Identity federation is a mature technology with wide deployment that has
been proven very successful for allowing heterogeneous domains and
technologies to interact with a minimum of integration efforts.

/Stefan

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 13 Sep 2010 17:25:06 +0200

> can be used in a common infrastructure.

I believe the USG will come to the same conclusion as their EU and Asian
counterparts did more than a decade ago:  We must develop our own client-side
security software since the platform vendors' offerings are insufficient as
well as all over the map.

In Sweden (just to take an example), the banks have essentially 100% market-share
on what could be characterized as the "security client" although they have purchased
the software from local ISVs.

This situation has effectively blocked Microsoft from rolling out Information Cards
(on any scale worth mentioning), although it is an *excellent* federation technology.

The root of the problem isn't actually the software but that all smart cards
are different in spite of the fact that they typically only perform simple
RSA sign operations.  Smart cards are close to the only devices which are not
just "peripherals" with simple well-defined interfaces, but "servers" that
rely on "clients".  The rest of the industry generally dumped the once quite
hyped client-server paradigm years ago due to cost and maintenance reasons.

The card industry OTOH continues in the *opposite direction* with Java Card 3
as the most recent example.

FWIW, I will (if I can manage to get the resources needed), introduce a
"dumbed down" smart card that indeed is just a simple peripheral that in
all its silliness allows full E2ES (End To End Security) provisioning using a
standard (future) browser, something the card industry will not be able to do
since producing replaceable commodities like disk drives is not on their
roadmap.  The same scheme is intended to also run in enhanced mobile
phones because these are even more crippled than PCs:

http://webpki.org/auth-token-4-the-cloud.html

Regarding trust issues in the commercial world, they are usually different
to that of the public sector.  In many cases "account integrity" is what
is called for and that does not require external identity vetting but a
suitable technical solution.  The scheme described above is intended to
be neutral regarding policy and thus address quite disparate and
evolving needs.

Anders

Stefan Santesson wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 13 Sep 2010 20:30:17 +0200

Anders,

A SAML federation can work regardless of what local client is used by the
user.

Which also means that you can use what ever card you like, or other
authentication technique if it just meet the set requirements of the
federation.

/Stefan

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 13 Sep 2010 20:59:31 +0200

Stefan Santesson wrote:

You asked for a discussion about auth tech.  Here it is :-)

> A SAML federation can work regardless of what local client is used by the

Absolutely, 99% probably use passwords but is that what NSTIC wants to invest in?

> authentication technique if it just meet the set requirements of the

Yes, but if NSTIC settles on cards they will end-up with Real ID based on FIPS201
which is another thing they may not want (or is it on their "hidden aggenda"?).
Anything else card-wise will only create support problems.

That consumer computers are not shipped with card-readers in spite of being
"promised" since a decade back is another hurdle they will face.
I guess they have bunkered up with BILLIONS of dollars for subsidizing
highly inconvenient, one-function, card readers?

The alternative to huge investments in cards, or medium investments in technology
development is that we continue using our Facebook, Google, and MSFT live Ids as
giant (sort of) federated "eID" systems powered by passwords!

But the latter is already in place so there is nothing more to do really...

Anders

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Sep 2010 02:10:49 +0200

I'm not sure what level of assurance they are looking for but SAML is in no
way bound to either the use of passwords or any other particular card
technology. Nor is it bound to one level of assurance.

So I don't see that they have to settle on any specific card type, just on
what level of assurance they require.

/Stefan  

On 10-09-13 8:59 PM, "Anders Rundgren" <[email-masked]> wrote:

>>> This situation has effectively blocked Microsoft from rolling out
>>> Information
>>> Cards

---

From: Stephen Wilson <[email-masked]>
Date: Tue, 14 Sep 2010 17:26:54 +1000

On 14/09/2010 4:59 AM, Anders Rundgren wrote:
>  Stefan Santesson wrote:
>
>  ... 99% probably use passwords but is that what NSTIC wants to
>  invest in?

Well that's an interesting question.  Is there any investment involved 
in the NS-TIC concept at all?  Or is it simply a description of a 
hoped-for "ecosystem" that will grow to deliver a range of 
authentication solutions, meeting the needs of governmet and of others?  
As I read it, the NS-TIC is accepting of (indeed, rejoicing in) the free 
market based evolution of solutions.  If 99% of them turn out to be 
password only, then the orthodoxy dictates that that's just the way it is.

But I myself would view that as a possible market failure.

So I wish that there was an investment plan associated with NS-TIC.

>  ... if NSTIC settles on cards they will end-up with Real ID based on
>  FIPS201 which is another thing they may not want (or is it on their
>  "hidden aggenda"?). Anything else card-wise will only create support
>  problems.

Anders, I don't accept your view that there is only one way to do 
smartcards.  In Europe and Asia we see a plethora of smartcards.  In 
Taiwan, people commonly carry four or five: a public health insurance 
smartcard, a PKI card for transacting with government, and any number of 
chipped banking cards (many of which were used from a very early stage 
for Internet banking).

If there is a FIPS 201 agenda behind NS-TIC, then I for one wish it 
well, and hope it comes out into the light! In FIPS 201 the US has 
spawned a tremendous de facto platform standard for strong 
authentication smartcards.  It needs tweaking for regular commercial 
use, but we're seeing that already with e.g. US Police co-opting FIPS 
201, and the newish business IDondemand basing its managed smartcards on 
FIPS 201.

There are occasional, rather too timid calls for smart health cards in 
the US (modelled on the successful Mt Sinai New York project) and for a 
chip upgrade of the Social Security Card.  Very logical.  And they need 
not scare anyone other than the paranoid.  If these sorts of projects 
were kept simple, and dedicated to reproducing today's functionality in 
the facility of a tamper-resistant, cloning-resistant chip -- i.e. don't 
for gods sake merge SSNs or health IDs with anything else, keep them 
separate -- then I think we would see enormous benefits.

>  That consumer computers are not shipped with card-readers in spite of
>  being "promised" since a decade back is another hurdle they will
>  face. I guess they have bunkered up with BILLIONS of dollars for
>  subsidizing highly inconvenient, one-function, card readers?

You keep saying this.  And I keep saying you're dead wrong.  Look at the 
Dell e-Series, and the HPs.  There are quite a few integrated smartcard 
readers already.  Here in Sydney my teenager has a school laptop with a 
built-in reader.  It's a total no brainer that if there were coordinated 
sustainable projects that used smartcards for online transactions, all 
notebook vendors would build in readers overnight.  They did it before 
in 2003 when Bill Gates announced the smartcard support in the Windows 
stack.  On that occasion, the marketplace failed to generate apps, and 
the readers where withdrawn.  That experience proves conclusively the 
propensity of vendors to include readers if the external dynamics make 
it worthwhile.

>  The alternative to huge investments in cards, or medium investments
>  in technology development is that we continue using our Facebook,
>  Google, and MSFT live Ids as giant (sort of) federated "eID" systems
>  powered by passwords!

I share your implied dismay at that scenario.

Cheers,

Steve.

Stephen Wilson
Managing Director
Lockstep Group

Phone +61 (0)414 488 851

www.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.
-----------------------------------------------------------------------
--- Asian SESAMES Awards Finalist 2010
--- Anthill Magazine 'Smart 100' (No. 25) 2009
--- Finextra Innovation Showcase 2009
--- Global Security Challenge Asia Top Five 2008
--- Australian Technology Showcase 2008

---

From: [email-masked]
Date: Thu, 16 Sep 2010 13:28:42 +0200

What about crypto micro SD cards? No reader need, not even telco operator. You can have client authentication, VPN access, signing features, etc. it´s not depending also on the mobile manufacturer or OS (blackberry, symbian, android, windows mobile, etc.)

Iñigo Barreira
Responsable del Área técnica
[email-masked]
945067705

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de Anders Rundgren
Enviado el: sábado, 28 de agosto de 2010 1:13
Para: Stephen Wilson
CC: pkix
Asunto: Re: [pkix] NSTIC - National Strategy for Trusted Identities inCyberspace

Stephen,
I share your view 100% about the wrongs with a single PKI/certificate.

This is also the reason why I have little faith in SIMs or external card
readers as the future for "Phone PKI".  SIMs will limit you to "Telco PKI"
while external readers are pretty clunky for dealing with multiple cards.

The *multiple* keys should therefore IMO be in the phone and provisioned
through secure and user-friendly on-line protocols.

I'm a (sort of an) optimist as well but I guess that it is the newcomers that
do not suffer from legacy that will take the lead.  Apple recently hired an
expert in these matters with the anticipated goal of making the iPhone a cool
payment tool. They will probably link the phone to a cloud-based payment
service to get away from dealing with telcos and card vendors.

That's the (IMO unwanted) side-effect of having a miserable provisioning technology:
we will be extremely dependent on super providers like Skype, PayPal, and Google since
the many independent trust networks we both are advocating for cannot cope with all
those crazy interoperability issues we have today.  Yes, I use super providers
because it is simple and simplicity is a hell of a lot more important than security
for adoption and adoption is really the only thing that counts in the long run.

I guess this level of designing is a bit over the top for those who feel that the
answer to every problem is an RFC with some ASN.1 in it, so we should probably let
this thread go to rest unless there are PKIX people who have interests in creating a
slightly better mobile world.

Anders

Stephen Wilson wrote:
> 
> 
> On 27/08/2010 10:15 PM, Anders Rundgren wrote:
>>  Moudrick M. Dadashov wrote:
>> > On 8/27/2010 2:09 PM, Anders Rundgren wrote:
>> >> On 2010-08-27 00:01, Stephen Wilson wrote:
>> >>
>> >>>> - Phones cannot [*] be provisioned with certificates
>> >>> But they can, via WPKI SIMs.
>> > The minimal requirement is a (W)PKI SIM where the client software
>> > can be provisioned by OTA upon clients desire. Some operators
>> > upgrade to (W)PKI SIM cards for free. :)
>>
>>  I was not referring to a local case where this may be possible but to
>>  the general case where it does not work. 
> 
> Anders, what you're doing is taking today's embryonic experience of a 
> particular form factor and tool kit, noting that it is not yet well 
> supported, and then extrapolating to say that there is something 
> fundamentally wrong with the form factor.  There are many reasons to 
> explain why SIM-based PKI and smartcard PKI have yet to take off.  All 
> new information technologies are expensive, awkward to use, and poorly 
> supported for a long time during the early part of their cycle. 
> 
> What makes things worse in PKI is the persistent utopian vision of 
> buidling one master "trust" infrastructure.  The word "trust" itself is 
> deeply problematic.  We wasted untold time and money striving to reduce 
> the number of certificates people carry (some still dream of just one), 
> through initiatives like Bridge CAs.  Why spend billions of dollars to 
> show that a certificate issued in one domain can be recognised in 
> another, when you could just as well carry on with two certificates?
> 
> I believe that the TCO to provision (from scratch) N different 
> non-interoperating certificates is smaller than the TCO of provisioning 
> one certificate that is recognised in N domains, for all values of N up 
> to some very big number.  Or maybe even all N period.  Interesting 
> research question: Find N.
> 
> 
> Back to NSTIC. Anyone else have a strong sense of deja vu? NSTIC (and 
> its template, the Identity Metasystem) are premised on the idea that we 
> can and *should* reuse identities issued in one context across into as 
> many other contexts as possible.  It's a lot like Big PKI all over 
> again.  The infrastructure needed to support cross-context "trust" is 
> gargantuan; the greatest cost component comes from Service Providers 
> changing their business rules and liability arrangements to accept 
> 'foreign' identities, and Identity Providers changing their business 
> rules and liability arrangements so their identities can be accepted for 
> applications over which they (the IDPs) have no control. 
> 
> 
>>  In the US I'm sure that the operators are entirely uninterested in
>>  PKI-enabled SIM since the USG has selected another (equally awkward)
>>  solution.
> 
> SIM based PKI and the US Government's PKI are different solution sets 
> aimed at different problem sets.  Unless telcos and smart phone app 
> developers are still laboring under the misapprehension that PKI is all 
> about having just one certificate, the Government's PKI should be of 
> little direct concern to them.  It's very sad if any PKI proponents are 
> still lobbying for one master solution, because good PKI is not about 
> master identification.  It's more about securing different 
> identities/credentials in different domains. 
> 
> Of course if government PKI can stimulate a market of tool kits and 
> gadgets then that is of enormous import to other PKI solution sets. It's 
> surely already happened with the Dell e-series notebooks coming out a 
> few years ago with integrated smartcard readers, responsive to the PIV 
> program.  And I see the $200 Blackberry reader as a wonderful thing.  
> The price will come down. I'm amazed that anyone in IT can look at the 
> high price of a second generation product and conclude that the 
> technology is wrong.  Do you not remember the $1000 CD ROM burners circa 
> 1990?  Or the $5000 5.25 inch Winchester HDDs (4 MB) circa 1980?
> 
>>  If fact, in the longer run I expect the SIM to become an "endangered
>>  specie" since it is not even holding our "telephone books" anymore
>>  (in general).
> 
> The SIM is not actually for storing the phone book.  Its purpose is to 
> cryptographically secure subscriber and carrier information, to 
> authenticate subscribers to the network.  SIMs have to embody a whole 
> lot of certifiable security features to prevent counterfeiting, which 
> makes it them well suited for holding digital certificates and 
> performing general purpose signing operations.
> 
> Cheers,
> 
> Steve, The Optimist, Australia.
> 
> Stephen Wilson
> Managing Director
> Lockstep *
> *
> Phone +61 (0)414 488 851
> 
> _www.lockstep.com.au
> 
> _/Lockstep Consulting provides independent specialist advice and analysis
> /
>> > Thanks, M.D. cell: +370-699-26662
>> >
>> >> Yes, if: - the customer has a contract with the phone operator -
>> >> the SIM-card supports PKI - you buy the services needed to be
>> >> able to provisioning SIMs - the phone has integrated WPKI
>> >> support
>> >>
>> >> Using my definition of can and a decade-long perspective of
>> >> no-avail I regard this as "theory".  Some of the handset vendors
>> >> have therefore on the USG's "command" added $200+ Bluetooth card
>> >> readers but I would be very surprised if the general market buys
>> >> into that:
>> >>
>> >> 
> http://na.blackberry.com/eng/ataglance/security/products/smartcardreader/
>> >>
>> >>
>> >>
> /Anders
>> >>
>> >>> On 27/08/2010 6:16 AM, Anders Rundgren wrote:
>> >>>
>> >>>>
>> >>> 
> http://www.whitehouse.gov/blog/2010/06/25/national-strategy-trusted-identities-cyberspace
>> >>>
>> >>>
>>
>> >>>> "For example, no longer should individuals have to remember
>> >>>> an
>> >>> ever-expanding
>> >>>> and potentially insecure list of usernames and passwords to
>> >>>> login into various online services" "...a digital certificate
>> >>>> on their cell phone..."
>> >>>>
>> >>>> Quite interesting and visionary IMHO.
>> >>>>
>> >>>> However ...
>> >>>>
>> >>>> - Computers are not [*] equipped with card readers
>> >>>
>> >>> That's what they said about CD-ROM drives c. 1990.
>> >>>
>> >>>> - Phones cannot [*] be provisioned with certificates
>> >>>
>> >>> But they can, via WPKI SIMs.
>> >>>
>> >>>> - Smart cards can only be provisioned off-line [*] but the
>> >>>> world is hooked on on-line
>> >>>
>> >>> But provisioning offline -- aka out-of-band -- is a good thing
>> >>> for security is it not?
>> >>>
>> >>> I agree with you Anders that the USB key is a terrific form
>> >>> factor.  If we added a crypto processor to the ubiquitous thumb
>> >>> drive then we could put a powerful virtual ID wallet into a lot
>> >>> of consumers' hands.
>> >>>
>> >>> USB keys are technically elegant but I have my doubts that a
>> >>> viable supply chain can be built for general purpose ID
>> >>> containers.  When a third party provisions a brand-less wallet,
>> >>> the user has to go from place to place -- either on line or out
>> >>> of band -- and have it topped up with different credentials.
>> >>> Even in technologically sophisticated societies like Malaysia
>> >>> and Hong Kong, maintaining a wallet of digital IDs in their
>> >>> smartcards has proven difficult.
>> >>>
>> >>> A more conservative approach -- in the sense that it preserves
>> >>> existing supply chains and legal arrangements -- is for
>> >>> existing "identity providers" (banks, governments, telcos etc.)
>> >>> to provision their credentials onto superior PKI-enabled media,
>> >>> like smartcards and smart phones.  The smartcard is so natural
>> >>> to use, and has such momentum in healthcare, government and
>> >>> payments, that I have high confidence the industry will
>> >>> overcome the practical obstacles: readers and drivers. Built-in
>> >>> smartcard readers are fast emerging already, and the driver
>> >>> problem has been solved before for other peripheral devices.
>> >>>
>> >>> Cheers,
>> >>>
>> >>> Stephen Wilson Managing Director Lockstep Group
>> >>>
>> >>> Phone +61 (0)414 488 851 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.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >> _______________________________________________ pkix mailing
>> >> list [email-masked] https://www.ietf.org/mailman/listinfo/pkix
>> >
>> >
>>
>>
>>
> 
> 
> ------------------------------------------------------------------------
>

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 16 Sep 2010 23:24:27 +0200

[email-masked] wrote:
> What about crypto micro SD cards? No reader need, not even telco operator.
 > You can have client authentication, VPN access, signing features, etc.
 > it´s not depending also on the mobile manufacturer or OS (blackberry,
 > symbian, android, windows mobile, etc.)

It sounds like a compelling solution but as far as I know it is not supported
by any other *vendor* than RIM (BlackBerry).  Relying on third-party card drivers
for things that evolve as quickly as mobile phones OSes is simply undoable
except for enterprises with good IT support.

There are other difficulties as well.  In spite of having maybe 16GB memory,
a micro SD smart card is typically quite restricted memory-wise which makes it a
one-issuer solution.  On the Internet we usually have many issuers and changing
miniature SD cards is hardly an option.

However, the by far biggest problem is the lack of an on-line protocol for provisioning
keys in smart cards.  In PCs it is a major nuisance; in phones it is fatal.

The handset vendors have had ample of time addressing this issue so the only
conclusion we can safely do is: Handset vendors don't care s**t about consumer
authentication solutions.

If the NSTIC folks want to do a contribution to the Cyberspace community they
should try to do something in the mobile space.  It is just "how" that's
the question.  Doing a private/public project with Microsoft, Apple or
Google isn't exactly politically correct but what is the alternative?
Writing RFCs that none of the big guns implement?

Nobody from NSTIC seems to monitor this list (or are very shy...) so maybe
NSTIC is just "fluff" without any substance?

Anders

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 16 Sep 2010 17:34:31 -0400

>keys in smart cards.  In PCs it is a major nuisance; in phones it is fatal.

So in a closed system, this is a solved problem via secure channels (supported by shared symmetric keys or asymmetric keys).  I (the token manager) gives you (the subscriber) an SD card for which I know the card authentication key.  You install it, and when you're ready to enroll a credential, you contact me and I can send commands to your token using that key.

Your problem is you want an open system, wherein there *is* no token manager--or more generally where the token issuer and credential issuer are different people and cannot (will not? Should not?) collaborate.  This is a much harder problem.

-- Tim

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Anders Rundgren
>Sent: Thursday, September 16, 2010 4:24 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [pkix] NSTIC - National Strategy for Trusted Identities
>inCyberspace
>
>to

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 17 Sep 2010 07:32:45 +0200

Miller, Timothy J. wrote:

Comparing apples and oranges is always difficult but it doesn't get any bit
easier when you throw in bananas as well :-)

> So in a closed system, 

The (for an NSTIC context) magic word is "closed"

> this is a solved problem via secure channels (supported by shared symmetric
 > keys or asymmetric keys).  I (the token manager) gives you (the subscriber)
 > an SD card for which I know the card authentication key.  You install it,
 > and when you're ready to enroll a credential, you contact me and I can send
 > commands to your token using that key.

Using PKIX-endorsed methods/formats such as CRMF, PKCS #10 which is all Microsoft,
Apple, Linux, and Google support *out-of-the-box*, you don't get very far since the
method above presumes "APDU" level communication between the issuer and card.

> Your problem is you want an open system, 

One person's "problem" could be another person's "opportunity". :-)

> wherein there *is* no token manager--or more generally where the token issuer 
 > and credential issuer are different people and cannot (will not? Should not?)
 > collaborate.  This is a much harder problem.

This is the banana comparison where we try to match a scheme that exists but
has only made it in few constrained CMSs (Card Management Systems), with a
open "vaporware" scheme intended to be featured in mobile phones and cheap
USB memory sticks as well as supported by any browser.

When/If the waporware token+protocol hits the market, it will (implicitly)
be decided if the problem was too hard or not.  I'm only aware of a single
(unsolvable) problem and that is "token flooding" by malicious middleware
which I doubt will be much of an issue; particularly not in mobile phones.

Personally, I believe "availability" is a bigger word than "security" and
to date none of the s.c. "contenders" have much to brag about :-|

Anders