Subject: [pkix] RFC 6170 (Cert Image) - Implementation Status

From: Anders Rundgren <[email-masked]>
Date: Tue, 14 Jan 2014 11:05:06 +0100

Since I haven't seen any signs of adoption of RFC 6170, I continued my
effort creating an alternative scheme which though only deals with user
certificate (actually credential) selection:

http://webpki.org/papers/PKI/webauth.pdf#page=4

The following sample shows the mechanics behind alternative scheme:
https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#Sample_Run

thanx,
Anders

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 14 Jan 2014 19:37:43 +0000

The referenced document appears to be based on a false premise.  It's interesting to see additional work, but it is mischaracterized as a "replacement" for HTTPS, just as it would be mischaracterized if it were claimed to be a replacement for IPSec.

Network association, communication session, and application session are three separate layers, not two, and all your complaints are based on that false conflation of communication and application layers.  CCA (as well as password-based TLS authentication mechanisms like SRP or SOKE) authenticate communication sessions.  Web application login passwords or PK login mechanisms do not authenticate communication sessions.

Re your second complaint, TLS does not lack a logout mechanism; it is trivial to discard whatever session context was created when a session was established, and once discarded the session cannot be resumed.  Standards for binding communication properties (such as authenticated endpoint identities) to applications have no more to do with TLS than they do with IPSec, and there is nothing the TLS protocol WG can or should do about that.  TLS and IPSec are tools to be used by applications; it's up to application developers (the "web community") to standardize use of those tools.

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Anders Rundgren
Sent: Tuesday, January 14, 2014 5:05 AM
To: [email-masked]
Subject: [pkix] RFC 6170 (Cert Image) - Implementation Status

Since I haven't seen any signs of adoption of RFC 6170, I continued my effort creating an alternative scheme which though only deals with user certificate (actually credential) selection:

thanx,
Anders
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 14 Jan 2014 21:24:33 +0100

> The referenced document appears to be based on a false premise.  It's interesting to see additional work, but it is mischaracterized as a "replacement" for HTTPS, just as it would be mischaracteriz…

Dave,

Variants of the described scheme is already used by many more browser users than HTTPS with CCA so I consider myself to be in pretty good company.
Google's U2F scheme
http://www.ietf.org/mail-archive/web/pkix/current/msg32832.html
builds on similar ideas AFAIK.

>
> Network association, communication session, and application session are three separate layers, not two, and all your complaints are based on that false conflation of communication and application layers.  CCA (as well as password-based TLS authentication mechanisms like SRP or SOKE) authenticate communication sessions.  

I would rather call it an impedance mismatch.

> Web application login passwords or PK login mechanisms do not authenticate communication sessions.

Exactly, they authenticate web sessions.  For that purpose there are currently no standards using PKI.

> Re your second complaint, TLS does not lack a logout mechanism; it is trivial to discard whatever session context was created when a session was established, and once discarded the session cannot b…

The HTTPS CCA logout/session problem has been known for over a decade and now it is too late to fix it.  There's no TLS session management in for example Java Servlets.
Do you object to using PKI and HTTPS the way I describe?

Anders

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 14 Jan 2014 20:56:18 +0000

Don't object at all to pursuing the idea.  But the TLS protocol WG has nothing to do with it, and the connection to RFC 6170 and PKIX is non-existent.  You don't propose any changes to the X.509 Certificate and CRL profile or cert management or status protocols.

So if this is a call for a BOF that happened to be sent to the PKIX mail list, fine.  If it's a call for a new PKIX or TLS work item, it's out of scope.

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]] 
Sent: Tuesday, January 14, 2014 3:25 PM
To: Kemp, David P.; [email-masked]
Subject: Re: [pkix] RFC 6170 (Cert Image) - Implementation Status

Dave,

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 14 Jan 2014 22:29:48 +0100

On 2014-01-14 21:56, Kemp, David P. wrote:
> Don't object at all to pursuing the idea.  

Good!

> But the TLS protocol WG has nothing to do with it, 

Right.  These guys are not even interested.

> and the connection to RFC 6170 and PKIX is non-existent.

The connection to RFC 6170 is that this scheme is an alternative approach which I also mentioned during the RFC development stages.

>   You don't propose any changes to the X.509 Certificate and CRL profile 

Right.  They are already perfect :-)

> or cert management or status protocols.

Well, I propose (point to rather) an entirely new cert management system which has almost nothing in common with the existing ones except for the core public key/certificate exchange.

Do we need that? Well, insert a blank/non-formatted PIV/CAC in any box of your choice and you will see that nothing happens.
Obviously these card weren't designed for on-line provisioning which made them useless for the mass market.

This is why I (and subsequently also Google) have come to the conclusion that a unified system that spans from the issuer down into the security hardware is required.

> So if this is a call for a BOF that happened to be sent to the PKIX mail list, fine.  If it's a call for a new PKIX or TLS work item, it's out of scope.

A scheme of the complexity I'm working with is out of scope for all SDOs, so you should rather see this as "information" only.

Google preferred doing their act in a closed industry forum with NDAs and high member fees.

Anders