[KI-LC] PKI vs Non-PKI based trust models
kantara at bobpinheiro.com
Tue Mar 15 00:43:25 EDT 2011
OK, but it's still possible to use certificates for strong
authentication of consumers if the certificate is contained on a USB
smartcard token. Of course, relying parties must accept certificates
for consumer authentication. Maybe there is a chicken-and-egg problem
here: RPs may have little interest until someone shows them a strong
authentication solution using certificates and smartcards that is
economically viable for adoption and use by consumers. But will
smartcard vendors devote resources to this until they see a consumer market?
The Smart Card Alliance <http://www.smartcardalliance.org/> is a member
of Kantara, and is also interested in getting smartcard technology into
the hands of consumers. The Smart Card Alliance is represented on the
Consumer Identity WG because they were hoping to get some insight into
consumer interest in, and adoption of, smartcards. Unfortunately, that
kind of insight doesn't exist within the Kantara community. At least
not within CIWG. Yet the Smart Card Alliance has an Identity Council
so there ought to be some opportunities for collaboration between
Kantara and Smart Card Alliance. There are at least two areas where our
interests probably overlap: use of smartcards for access to patient
health records, and smartcards as form factors for identity credentials
usable within the "ecosystem" enabled by the National Strategy for
Trusted Identities in Cyberspace.
Another Kantara member is Fraunhofer FOKUS, which is the host of the
next Kantara meeting, and is also a provider (?) of German eID cards.
And although there seems to be no formal working relationships between
Kantara and Microsoft, smartcards were used to provide secure U-Prove
tokens for an RSA demo by splitting the token's private key between the
user's computing device and the smartcard.
So there seems to be a number of areas of where certificates and
smartcards can be used for strong authentication and/or high assurance
claims. If these topics are of sufficient interest within Kantara, and
resources can be found, perhaps there are opportunities for
collaboration with Smart Card Alliance and others.
On 3/14/2011 6:25 PM, John Bradley wrote:
> I spent many years with the PKI Forum and other places pushing the
> better browser support rock up the hill to no great success.
> There has been no detectable improvement in mutual TLS support. On
> the other hand EV certs got in because there was a clear revenue model
> to the PKI Forum participants.
> Some of the problem relates to TLS itself and the rest with the
> browser venders.
> If I had to get one thing from them it would be a way to do ephemeral
> keys for HoK as STORK and others have been asking for, also to no
> great success.
> If someone wants to put together a gang to take on the browser venders
> I am in, but I am realistic about any real progress after 10 years or
> so of trying.
> John B.
> On 2011-03-14, at 5:56 PM, Colin Wallis wrote:
>> So the problem with client side Certs is the way they are
>> implemented..with security in mind only, not privacy. 'Promiscuous'
>> is the label given to them down here..
>> That's why the NZ Government does not use them in its consumer online
>> service strategy…
>> And I might point out that it's too much of a generalisation for my
>> comfort to say to that 'eGov prefers PKI' (Rainer's 5th bullet)
>> The lines between law enforcement/security (with no privacy) and
>> consumer service/security (with privacy) seem to be getting blurred
>> in some folks' minds (certainly not Bob's, nor John's..)
>> <<BP:For example, could Kantara have a role to play in making it
>> practical to provision client-side certificates to consumers, so that
>> websites can enable the use of two-way SSL for consumers who have
>> client-side certificates>>
>> Maybe, but I think it won't be listened to. The change has got to
>> take place at the doors (hearts and minds) of the browser vendors,
>> and the logical co-ordination point for that is the CA Browser
>> forum. I'm trying to think of the directional pressure that might
>> persuade them to tackle this problem - the Data Protection & Privacy
>> Commissioners group? Maybe. Kantara? Nope. At least not unless KI is
>> pushing at an open door..
>> *From:*lc-bounces at kantarainitiative.org
>> <mailto:lc-bounces at kantarainitiative.org>[mailto:lc-bounces at kantarainitiative.org]*On
>> Behalf Of*Bob Pinheiro
>> *Sent:*Tuesday, 15 March 2011 6:16 a.m.
>> *To:*John Bradley
>> *Cc:*dg-bctf at kantarainitiative.org
>> <mailto:dg-bctf at kantarainitiative.org>; FI WG; Curry Patrick; Kantara
>> Leadership Council Kantara
>> *Subject:*Re: [KI-LC] PKI vs Non-PKI based trust models
>> Regarding U-Prove and failed efforts at consumer PKI:
>> For high assurance consumer applications that (should) require strong
>> authentication, such as online banking, payments, access to patient
>> health records and other sensitive personal information, what are the
>> possibilities for doing strong authentication?
>> Since PKI doesn't seem to be a realistic possibility at the consumer
>> level (at least not now), it seems that the current choice is limited
>> to one-time passwords, at least for consistency with IAF and NIST
>> 800-63 v1.0.2.
>> U-Prove tokens are a potentially viable method for transmitting high
>> assurance claims to a RP for these consumer apps. But even so, the
>> consumer will still need to strongly authenticate to either an
>> identity provider (who issues the tokens), or to a cloud-based active
>> client / token agent / claims agent. Or both (??). With the demise
>> of Cardspace, the use of a self-issued infocard for performing this
>> authentication seems to be out.
>> Joni has asked for volunteers for a strategy subcommittee to help
>> Kantara become more effective, attract more members, etc. I'm
>> wondering whether one possible strategic goal for Kantara could be to
>> help transform PKI into something that is practical for use by consumers.
>> For example, could Kantara have a role to play in making it practical
>> to provision client-side certificates to consumers, so that websites
>> can enable the use of two-way SSL for consumers who have client-side
>> A second possible strategic direction is to help in getting U-Prove
>> to be implemented in a way that is usable by consumers. There is a
>> related effort in the form of a claims agent working group in
>> Identity Commons, but that is not specific to U-Prove.
>> Maybe these thoughts are best discussed in the strategy subcommittee
>> instead, but I just wanted to put this out there and get some sense
>> as to whether anyone thinks these might be reasonable goals to
>> pursue. Or not? Would such goals stray too far from Kantara's mission?
>> Bob P.
>> On 3/14/2011 10:50 AM, John Bradley wrote:
>> I helped start Xcert software (now RSA KeyOn) 12 years ago to work on
>> federated identity issues using PKI client Auth. Why PKI failed in
>> the consumer/internet space is a big topic.
>> I should also mention that u-prove (zero knowledge prrof)
>> cryptography contains elements of both certificates and
>> assertions. I have limited expectations for any short term
>> traction on that however.
>> On 2011-03-14, at 8:08 AM, Rainer Hörbe wrote:
>> John, Patrick and I had a discussion about the pros and cons of
>> federation models based on credentials versus assertions. The
>> attached document is a preliminary result with conclusions like
>> * PKI and non-PKI federation models need to be combined in
>> most cases at higher LoA
>> * To implement a federation an RFC 3647-style policy is
>> insufficient; A more complete Trust Framework is needed
>> * Whereas the Higher Education sector favors brokered trust,
>> e-Government and Industry prefer the PKI approach. But it
>> is not a question of one way or the other.
>> Request for feedback:
>> I wonder where this discussion should be homed. FIWG, BCTF and
>> TFMM are related, and it is also an extrakantarian issue. Any
>> interest to take over this discussion?
>> - Rainer
>> <pki vs non-pki.pdf>
>> CAUTION: This email message and any attachments contain information
>> that may be confidential and may be LEGALLY PRIVILEGED. If you are
>> not the intended recipient, any use, disclosure or copying of this
>> message or attachments is strictly prohibited. If you have received
>> this email message in error please notify us immediately and erase
>> all copies of the message and attachments. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the LC