Re: [TLS] CertficateRequest extension encoding

On 2016-09-06 16:15, Peter Gutmann wrote:
> David Benjamin <davidben@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
>