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 <[email protected]>
wrote:
> On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov <[email protected]>
> 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:[email protected]]
>> Sent: Tuesday, September 6, 2016 8:36 AM
>> To: Peter Gutmann <[email protected]>; David Benjamin <
>> [email protected]>; Andrei Popov <[email protected]>; Ilari
>> Liusvaara <[email protected]>; [email protected]
>> Subject: Re: [TLS] CertficateRequest extension encoding
>>
>> On 2016-09-06 16:15, Peter Gutmann wrote:
>> > David Benjamin <[email protected]> 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
>> > [email protected]
>> > https://www.ietf.org/mailman/listinfo/tls
>> >
>>
>> _______________________________________________
> TLS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
