On 2016-09-06 16:15, Peter Gutmann wrote:
David Benjamin <david...@chromium.org> writes:
Either way I imagine our stack will just keep on ignoring it, so I don't feel
about this all too strongly. But the topic came up so I thought I'd suggest
this.
I ignore it too. Client certs are so rare, and so painful to deploy, that I'm
not going to make things harder on users by adding complex and opaque
filtering to prevent them from working. My approach is to specify as few
constraints as possible, the client submits whatever certificate it has, and
it's then decided based on a whitelist for which the server can very clearly
report "not on the whitelist" when it rejects it. The design seems to be
based on the idea that each client has a smorgasbord of certs and the server
can specify in precise detail in advance which one it wants, when in reality
each client has approximately zero certs, and the few that do have one just
want the one they've got to work.
May I add some nuances here?
Client-certificates are *extensively* used for secure box-to-box communication.
Existing selection methods suffice (there's usually none on the client side).
Client-certificates for user authentication on the Web through HTTPS is a small
and diminishing activity. The decision by the browser vendors dropping support
for on-line enrollment is likely to further limit this use case which make
improvements in selection/filtering pretty uninteresting.
Client-certificates for user authentication on the Web through through
proprietary
("FIDO like") application level protocols is fairly big. Half of the Swedish
population use such a scheme for e-government and bank access. It uses an ugly
(and non-secure) OOB-method to make it "Web compatible". This use-case is
(of course) not of an issue for the TLS WG but may be of some interest for
people currently using client certificates for Web authentication.
Anders
Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
