Re: cert image I-D

["Anders Rundgren" <anders.rundgren@xxxxxxxxx>]

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" <trevorf@xxxxxxxxxxxxxxxxxxxxxx>
To: "Anders Rundgren" <anders.rundgren@xxxxxxxxx>; <ietf-pkix@xxxxxxx>; "Stephen Kent"
<kent@xxxxxxx>
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: 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