David, If we're changing this structure of CertificateRequest, I have two suggestions.
1) Move DistinguishedName out of the structure and define it as a TLS-style extension. It's not a required field. 2) Remove SignatureScheme from structure, and instead change the behavior of the the "signature_algorithms" extension to include all server-supported SignatureSchemes in the ServerHello in descending order of preference. This will result in a much more compact message structure that can easily be re-purposed for post-handshake server auth and other optional extensions to TLS 1.3: struct { opaque certificate_request_context<1..2^8-1>; CertificateRequestExtension certificate_extensions<0..2^16-1>; } CertificateRequest; Nick On Thu, Sep 22, 2016 at 6:26 PM David Benjamin <david...@chromium.org> wrote: > On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov <andrei.po...@microsoft.com> > wrote: > >> > But it's OID-specific how the matching works, isn't it? >> Correct, and initially we define matching for KU and EKU. These are the >> OIDs I've got the most customer requests for. I expect that we will want to >> define matching rules for other OIDs over time, in separate specs. This new >> proposal allows multiple sets of matching rules for each OID, which >> certainly increases flexibility. >> >> David, do you care enough to write your proposal down as a PR, so that we >> can discuss the specifics? >> > > Apologies for the delay. Been a busy few weeks. This is roughly what I was > thinking: > https://github.com/tlswg/tls13-spec/pull/656 > > What do you think? > > Again, I don't actually care about this, so if you and others who would > use this mechanism prefer it as it is, I have no qualms. This is a "pull > suggestion", not a "pull request". :-) > > David > > >> Thanks, >> >> Andrei >> >> -----Original Message----- >> From: Anders Rundgren [mailto:anders.rundgren....@gmail.com] >> Sent: Tuesday, September 6, 2016 8:36 AM >> To: Peter Gutmann <pgut...@cs.auckland.ac.nz>; David Benjamin < >> david...@chromium.org>; Andrei Popov <andrei.po...@microsoft.com>; Ilari >> Liusvaara <ilariliusva...@welho.com>; tls@ietf.org >> Subject: Re: [TLS] CertficateRequest extension encoding >> >> 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls