RE: cert image I-D

["Bajaj, Siddharth" <SBajaj@xxxxxxxxxxxx>]

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


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" <trevorf@xxxxxxxxxxxxxxxxxxxxxx>
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
> 
> -----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
>