Subject: cert image I-D

From: Stephen Kent <[email-masked]>
Date: Wed, 13 May 2009 13:56:17 -0400

Folks,

I have reviewed the discussion on the list re Stefan's cert image 
proposal. While there were comments for and against, the positive 
comments, especially from folks who are in a position to make use of 
this feature, were persuasive.

We will proceed with this a a new PKIX WG work item.  This is not a 
guarantee that the WG will approve a document, but rather that we 
will explore approaches to achieving the goals described by Stefan 
and try to come to consensus on a specific technical approach. We can 
decide later whether this is standards track, experimental or even 
informational.

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 13 May 2009 22:39:45 +0200

I believe this effort suffers from more technical hurdles than the authors
are aware of.  Just defining exactly how and where in a browser's TLS
client-cert-auth the image is supposed to be introduced is not trivial
because there is a battle going on between the browser/OS and the
vendors of card middleware for the GUI.  Currently the latter often
does a better job than the rather complacent browser vendors.

The sample given by Siddharth probably utilized some kind
of application-level thingy which BTW points to another issue:
Quite a bunch of current PKI implementations actually do not use TLS-
client-cert-auth but rather use proprietary app-level authentication schemes.
One the few non-internal PKIs used by the USG, namely the
USPTO's filing system is apparently one of these systems.

It is also worth noting that Information Cards do not use TLS-client
cert-auth even when the primary authentication is based on PKI.
Probably MSFT drew the same conclusion as many others have
before them: TLS-client-cert-auth is an ugly beast on the web,
app-level authentication works better; it is at least much prettier :-)

Although providing an "upgrade path" sounds like a good solution
it often works in the opposite way by "the least common denominator rule".
60% of enterprises use IE6 despite been EOLed since 5 years back!

Time will tell, but personally I do not believe you get very far unless you
take on the entire browser/keystore/provisioning/authentication space
otherwise the incentive for changing (anything) will simply be too small.

Which is thus exactly what my counter-proposal does........

Anders

----- Original Message ----- 
From: "Stephen Kent" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, May 13, 2009 19:56
Subject: cert image I-D

Folks,

Steve

---

From: Trevor Freeman <[email-masked]>
Date: Wed, 13 May 2009 23:26:25 +0000

Hi Anders,

I agree that this work faces a number of technical challenges, however the authors are a bunch of bright people and they will rise to meet the challenge.

On one point we do agree and that is the 80%+ case for web based authentication using client certificates will be via information cards. The fat lady has sung on that point. The reason that will be the case is that the authorization to access the data needs a richer set of information than that contained within the X.509 certificate alone so they need to present a set of claims e.g. a SAML token not just a certificate. As you point out, information cards already handle the case of presenting a graphical image to the user.

Another reason why information cards are the 80% case is that the web 2.0 standard also addresses in more detail the question of what is needed to do to access the site because the site publishes access policy via WS-Policy. The information card client knows in much greater detail what is required and therefore would not require the user to make a choice they did not comprehend.

That said there are other scenarios where you have the potential for client certificate authentication which are not web 2.0 based e.g. IMAP where this work may be useful.

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anders Rundgren
Sent: Wednesday, May 13, 2009 1:40 PM
To: [email-masked]; Stephen Kent
Subject: Re: cert image I-D

Anders

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, May 13, 2009 19:56
Subject: cert image I-D

Folks,

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 14 May 2009 01:40:14 +0200

Trevor,

Agreeing with many things I would like to add one thing.

Having spent considerable time with the information cards concept and having
been through long discussions with the information card team at Microsoft, I
can see no conflict.

Even if information card is used to provide a UI for client certificates,
this UI still need to come up with an image to represent that certificate.

Information card has previously been a candidate for consuming RFC 3709
images and that is by no means less true if we add another more useful
image.

/Stefan

On 09-05-14 1:26 AM, "Trevor Freeman" <[email-masked]>
wrote:

> 
> Hi Anders,
> 
> I agree that this work faces a number of technical challenges, however the
> authors are a bunch of bright people and they will rise to meet the challenge.
> 
> On one point we do agree and that is the 80%+ case for web based
> authentication using client certificates will be via information cards. The
> fat lady has sung on that point. The reason that will be the case is that the
> authorization to access the data needs a richer set of information than that
> contained within the X.509 certificate alone so they need to present a set of
> claims e.g. a SAML token not just a certificate. As you point out, information
> cards already handle the case of presenting a graphical image to the user.
> 
> Another reason why information cards are the 80% case is that the web 2.0
> standard also addresses in more detail the question of what is needed to do to
> access the site because the site publishes access policy via WS-Policy. The
> information card client knows in much greater detail what is required and
> therefore would not require the user to make a choice they did not comprehend.
> 
> That said there are other scenarios where you have the potential for client
> certificate authentication which are not web 2.0 based e.g. IMAP where this
> work may be useful.
> 
> Trevor
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 14 May 2009 20:56:38 +0200

Hi Trevor,
I also consider the authors a bunch of bright people.

However writing an I-D describing how a image URL can be
fitted to a certificate, without actually publishing a mockup on how
this I-D could be mapped to the existing browser GUI's is begging
for problems.

It is also worth noting that at least one of the external parties mentioned
as input also have web-based signatures as one of their core offerings.
But this requirement (which is much bigger than cert-images), has to date
been *ignored* by MSFT.   In fact, government and banks in the EU
spend at least $100M annually on developing browser-client-PKI SW
since they [rightfully] experience the current state of things as "miserable".

That MSFT (according to W3C/WHATWG...) intends to support the
HTML5 <keygen> tag is yet another indication that the people who work with
browsers at MSFT (and Apple, Nokia, Google, Mozilla, Opera etc), do not
have sufficient information what the requirement are on browser-PKI.
<keygen>: on-line key-provisioning without even supporting PIN-codes!

Subsequently the very same governments and banks quite often also develop
their own provisioning stuff; what else could they possibly do?

I'm sure a cert-image RFC will pass with flying colors but that's about
the only action there will be.

Anders
puzzled

----- Original Message ----- 
From: "Trevor Freeman" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>; "Stephen Kent"
<[email-masked]>
Sent: Thursday, May 14, 2009 01:26
Subject: RE: cert image I-D

Hi Anders,

I agree that this work faces a number of technical challenges, however the authors are a bunch of
bright people and they will rise to meet the challenge.

On one point we do agree and that is the 80%+ case for web based authentication using client
certificates will be via information cards. The fat lady has sung on that point. The reason that
will be the case is that the authorization to access the data needs a richer set of information than
that contained within the X.509 certificate alone so they need to present a set of claims e.g. a
SAML token not just a certificate. As you point out, information cards already handle the case of
presenting a graphical image to the user.

Another reason why information cards are the 80% case is that the web 2.0 standard also addresses in
more detail the question of what is needed to do to access the site because the site publishes
access policy via WS-Policy. The information card client knows in much greater detail what is
required and therefore would not require the user to make a choice they did not comprehend.

That said there are other scenarios where you have the potential for client certificate
authentication which are not web 2.0 based e.g. IMAP where this work may be useful.

Trevor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anders
Rundgren
Sent: Wednesday, May 13, 2009 1:40 PM
To: [email-masked]; Stephen Kent
Subject: Re: cert image I-D

Anders

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, May 13, 2009 19:56
Subject: cert image I-D

Folks,

Steve

---

From: "Bajaj, Siddharth" <[email-masked]>
Date: Fri, 15 May 2009 15:58:40 -0700

Hi Anders/Trevor,

Thanks for emails and thoughts - 

Most likely multiple identity/authentication technologies will co-exist
in the 
Foreseeable future - X.509 certificates, Information Cards, and whatever
else.

What we are trying to do is to provide a building-block that user-agents
can leverage 
to provide a better user experience around X.509 certs.

I understand that the Information Cards are not using TLS/SSL auth - the
analogy
that I was trying to drive in my earlier email was that - the credential
selector 
UI for Information Cards already has the capability to display card
images. 
this extension will enable client platforms to use a similar user
interface 
paradigm for certificate selection, if they choose to implement it. This
will 
enable the client to provide comsistent/similar visual abstraction to
the user 
irrespective of the underlying technology. 

I want to acknowledge that this is not something that will solve all the
usability issues with PKI today,
However, we think that this is low-hanging fruit- where we can improve
the experience of 
technology (X.509,PKI) that is already deployed without re-inventing a
lot of the stack.

Last but not the least, it is very likely that something like the
KeyGen2 proposal may get 
momentum in the future and want to point out that this work can co-exist
with the new
stack that comes out of that effort. 

Thanks,

Siddharth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Wednesday, May 13, 2009 4:40 PM
To: Trevor Freeman; Anders Rundgren; [email-masked]; Stephen Kent
Subject: Re: cert image I-D

Trevor,

Having spent considerable time with the information cards concept and
having been through long discussions with the information card team at
Microsoft, I can see no conflict.

Even if information card is used to provide a UI for client
certificates, this UI still need to come up with an image to represent
that certificate.

/Stefan

On 09-05-14 1:26 AM, "Trevor Freeman" <[email-masked]>
wrote:

> 
> Hi Anders,
> 
> I agree that this work faces a number of technical challenges, however

> the authors are a bunch of bright people and they will rise to meet
the challenge.
> authentication using client certificates will be via information 
> cards. The fat lady has sung on that point. The reason that will be 
> the case is that the authorization to access the data needs a richer 
> set of information than that contained within the X.509 certificate 
> alone so they need to present a set of claims e.g. a SAML token not 
> just a certificate. As you point out, information cards already handle
the case of presenting a graphical image to the user.
> 
> Another reason why information cards are the 80% case is that the web 
> 2.0 standard also addresses in more detail the question of what is 
> needed to do to access the site because the site publishes access 
> policy via WS-Policy. The information card client knows in much 
> greater detail what is required and therefore would not require the
user to make a choice they did not comprehend.
> 
> That said there are other scenarios where you have the potential for 
> client certificate authentication which are not web 2.0 based e.g. 
> IMAP where this work may be useful.
> 
> Trevor
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anders Rundgren
> I believe this effort suffers from more technical hurdles than the 
> authors are aware of.  Just defining exactly how and where in a 
> browser's TLS client-cert-auth the image is supposed to be introduced 
> is not trivial because there is a battle going on between the 
> browser/OS and the vendors of card middleware for the GUI.  Currently 
> the latter often does a better job than the rather complacent browser
vendors.
> 
> The sample given by Siddharth probably utilized some kind of 
> application-level thingy which BTW points to another issue:
> One the few non-internal PKIs used by the USG, namely the USPTO's 
> filing system is apparently one of these systems.
> 
> Probably MSFT drew the same conclusion as many others have before 
> them: TLS-client-cert-auth is an ugly beast on the web, app-level 
> authentication works better; it is at least much prettier :-)
> 
> Although providing an "upgrade path" sounds like a good solution it 
> often works in the opposite way by "the least common denominator
rule".
> Time will tell, but personally I do not believe you get very far 
> unless you take on the entire 
> browser/keystore/provisioning/authentication space otherwise the
incentive for changing (anything) will simply be too small.
> guarantee that the WG will approve a document, but rather that we will

> explore approaches to achieving the goals described by Stefan and try 
> to come to consensus on a specific technical approach. We can decide 
> later whether this is standards track, experimental or even 
> informational.
> 
> Steve
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 16 May 2009 10:14:25 +0200

Hi Guys,

Siddharth wrote:
>the experience of technology (X.509,PKI) that is already deployed
>without re-inventing a lot of the stack.

It is of course up to you to decide, but AFAICT there is no low-hanging
fruit when it comes to upgrading user-agents.

That is, if you want to see this running (ever) you should also consider
the adoption which IMHO should begin with enabling the functionality
in browsers.  Contributing code to Mozilla would be a good start
because then you get a reference design which I think is badly needed.

I'm personally going to cater for the adoption of KeyGen2[*] by making
(if I have time...) the implementation available as Open Source for WebKit
which has some 50% of the smart phone market share.  An advantage with
the mobile phone is that you avoid the unwieldy middleware situation in
PCs where the platform "competes" for the GUI with third-party middleware
which makes the user-experience quite horrible.  The tremendous success
of the iPhone indicates that there is more room for GUI innovation in this
space than in PCs.  As I have already said, the need for cert-images in
mobiles phones is also much bigger than on PCs because they can host
multiple credentials and also have limited screen real estate.

It will take 5 years or more to see who got it right :-)
The biggest hurdle is still status quo.

Anders

*] KeyGen2 is just one of the components of a completely revised
PKI client, loosly tailored after already established schemes in the EU.