RE: cert image I-D

[Trevor Freeman <trevorf@xxxxxxxxxxxxxxxxxxxxxx>]

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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Anders Rundgren
Sent: Wednesday, May 13, 2009 1:40 PM
To: ietf-pkix@xxxxxxx; Stephen Kent
Subject: Re: cert image I-D


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" <kent@xxxxxxx>
To: <ietf-pkix@xxxxxxx>
Sent: Wednesday, May 13, 2009 19:56
Subject: cert image I-D



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