Re: [TLS] CertficateRequest extension encoding

2017-04-26 Thread Ilari Liusvaara
On Mon, Sep 05, 2016 at 09:46:51PM +, Andrei Popov wrote: > > Do we need to make it this flexible? The idea was to avoid adding > complexity to the certificate filtering code in the TLS stack, and > instead filter by OIDs in the PKI library. PKI libraries already > inspect and match OID

Re: [TLS] CertficateRequest extension encoding

2016-10-10 Thread Martin Rex
Geoffrey Keating wrote: > > A typical macOS system will have many issued certs, typically with at > most one that will work for any particular web site or web API. So > the filter is somewhat important for client certs to work there in any > kind of user-friendly way. In particular if the

Re: [TLS] CertficateRequest extension encoding

2016-09-23 Thread Martin Thomson
On 24 September 2016 at 10:35, Nick Sullivan wrote: > 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

Re: [TLS] CertficateRequest extension encoding

2016-09-23 Thread Nick Sullivan
t;> use this mechanism prefer it as it is, I have no qualms. This is a "pull >>> suggestion", not a "pull request". :-) >>> >>> David >>> >>> >>>> Thanks, >>>> >>>> Andrei >>>> >>>

Re: [TLS] CertficateRequest extension encoding

2016-09-23 Thread David Benjamin
om: 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>; tl

Re: [TLS] CertficateRequest extension encoding

2016-09-23 Thread Nick Sullivan
ren [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 <ilaril

Re: [TLS] CertficateRequest extension encoding

2016-09-23 Thread Andrei Popov
Anders Rundgren <anders.rundgren@gmail.com>; Peter Gutmann <pgut...@cs.auckland.ac.nz>; Ilari Liusvaara <ilariliusva...@welho.com>; tls@ietf.org Subject: Re: [TLS] CertficateRequest extension encoding On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov <andrei.po...@mic

Re: [TLS] CertficateRequest extension encoding

2016-09-22 Thread David Benjamin
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 sta

Re: [TLS] CertficateRequest extension encoding

2016-09-06 Thread Geoffrey Keating
Peter Gutmann writes: > David Benjamin 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.

Re: [TLS] CertficateRequest extension encoding

2016-09-06 Thread Andrei Popov
gren@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] Certficat

Re: [TLS] CertficateRequest extension encoding

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

Re: [TLS] CertficateRequest extension encoding

2016-09-06 Thread Peter Gutmann
David Benjamin 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

Re: [TLS] CertficateRequest extension encoding

2016-09-05 Thread David Benjamin
On Mon, Sep 5, 2016 at 5:46 PM Andrei Popov wrote: > Ø A CertificateExtension is a hint to the client about what kind of > certificates are acceptable. We have a registry of u16s for them. Clients > ignore extensions they don't understand, so it is ultimately on the

Re: [TLS] CertficateRequest extension encoding

2016-09-05 Thread Andrei Popov
Ø And how is the value encoded? Using the same encoding as extnValue payload of respective extension in X.509 certifcates? The same encoding as the respective extension in X.509 certificates (please feel free to suggest the language to make this clearer). Ø A CertificateExtension is a hint

Re: [TLS] CertficateRequest extension encoding

2016-09-04 Thread David Benjamin
Apologies, I hit 'Send' too early. Finished a sentence below: On Sun, Sep 4, 2016 at 1:41 PM David Benjamin wrote: > I have no involvement in systems that would want this (our implementation > just ignores it), but it seems a TLS-style registry would be better than >

Re: [TLS] CertficateRequest extension encoding

2016-09-04 Thread David Benjamin
I have no involvement in systems that would want this (our implementation just ignores it), but it seems a TLS-style registry would be better than using OIDs anyway. Concretely: A CertificateExtension is a hint to the client about what kind of certificates are acceptable. We have a registry of

[TLS] CertficateRequest extension encoding

2016-09-04 Thread Ilari Liusvaara
How are the OIDs and values in CertificateRequest extensions encoded exactly (I can't make it out from the text)? Does the OID part have the ASN.1 OID TLV tag and length (e.g. is EKU 0x55 0x1D 0x25 or 0x06 0x03 0x55 0x1D 0x25)? And how is the value encoded? Using the same encoding as extnValue