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
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
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
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
>>>>
>>>
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
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
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
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
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.
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
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,
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
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
Ø 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
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
>
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
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
17 matches
Mail list logo