Re: [TLS] CertficateRequest extension encoding
Hi Ilari, I don't have this implemented yet, but yes, tag/length should be included. Same as in the actual cert. Cheers, Andrei -Original Message- From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] Sent: Wednesday, April 26, 2017 10:04 AM To: Andrei Popov Cc: David Benjamin ; tls@ietf.org Subject: Re: [TLS] CertficateRequest extension encoding 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 values, so this should be a relatively small > change for them. Haven't found an answer to this yet... How are the OIDs encoded exactly? Does the value of 'certificate_extension_oid' include redundant OBJECT IDENTIFIER tag and length, or not? That is, is id-pe-nsa [1.3.6.1.5.5.7.1.23] (just to pick an example) in certificate_extension_oid field encoded as: 1) 2B 06 01 05 05 07 01 17 (no tag/length) 2) 06 08 2B 06 01 05 05 07 01 17 (tag/length included). ? -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] CertficateRequest extension encoding
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 values, so this should be a relatively small > change for them. Haven't found an answer to this yet... How are the OIDs encoded exactly? Does the value of 'certificate_extension_oid' include redundant OBJECT IDENTIFIER tag and length, or not? That is, is id-pe-nsa [1.3.6.1.5.5.7.1.23] (just to pick an example) in certificate_extension_oid field encoded as: 1) 2B 06 01 05 05 07 01 17 (no tag/length) 2) 06 08 2B 06 01 05 05 07 01 17 (tag/length included). ? -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] CertficateRequest extension encoding
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 server provides no > guidance, the UI will ask the user, presenting a dialog containing > many certificates the user is not aware they have, leading to complete > user confusion. In the past, Safari on MAC entirely ignored the server-asserted contents of certificate_authorities in the TLS CertificateRequest handshake message, and would offer *all* possible client certs to the user. Has this bug been fixed in Safari? I remember customer messages where clients were refused that were erroneously sending AppleID client certs... -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] CertficateRequest extension encoding
On Sat, Sep 24, 2016 at 01:17:22AM +, Nick Sullivan wrote: > Signature algorithm support is typically per-connection, not per > certificate request. If you're doing multiple post-handshake > authentications then (2) reduces the amount of redundant data sent on > subsequent authentications. Furthermore, it opens the door for unsolicited > post-handshake authentication in future extensions to the protocol. > > Clients only need to stash a copy of it if they support client > authentication, which in my opinion should be optional. Perhaps support for > post-handshake authentication should be signaled with an extension. That > way the server SignatureSchemes could be carried in that extension, rather > than overloading the "signature_algorithms" extension. But the client requires that signature list to perform authentication. It is not optional for the in-handshake authentication. Also, I think the post-handshake auth is just annoying (and it comes with security problems currently), so I would like to be able to just not implement it. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] CertficateRequest extension encoding
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 "signature_algorithms" extension to include all server-supported > SignatureSchemes in the ServerHello in descending order of preference. This is my preference too. I get that this means that you have to remember more if you might support client authentication, but it removes yet another bespoke parser and extension point. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] CertficateRequest extension encoding
Signature algorithm support is typically per-connection, not per
certificate request. If you're doing multiple post-handshake
authentications then (2) reduces the amount of redundant data sent on
subsequent authentications. Furthermore, it opens the door for unsolicited
post-handshake authentication in future extensions to the protocol.
Clients only need to stash a copy of it if they support client
authentication, which in my opinion should be optional. Perhaps support for
post-handshake authentication should be signaled with an extension. That
way the server SignatureSchemes could be carried in that extension, rather
than overloading the "signature_algorithms" extension.
On Fri, Sep 23, 2016 at 5:56 PM David Benjamin
wrote:
> (1) seems reasonable. I don't have strong views there. I even jokingly
> suggested it in the PR description.
>
> I do not like (2). This requires implementations stash a copy of the
> signature algorithms without known a priori whether it will be used or not.
> And it means when receiving a CertificateRequest, you have to go check that
> the extension was provided at all. I think that should stay bound to the
> CertificateRequest and as a required field.
>
> On Fri, Sep 23, 2016 at 8:35 PM Nick Sullivan
> wrote:
>
>> 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
>> wrote:
>>
>>> On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov
>>> 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 ; David Benjamin <
>>>> david...@chromium.org>; Andrei Popov ;
>>>> Ilari Liusvaara ; tls@ietf.org
>>>> Subject: Re: [TLS] CertficateRequest extension encoding
>>>>
>>>> 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, 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 whate
Re: [TLS] CertficateRequest extension encoding
(1) seems reasonable. I don't have strong views there. I even jokingly
suggested it in the PR description.
I do not like (2). This requires implementations stash a copy of the
signature algorithms without known a priori whether it will be used or not.
And it means when receiving a CertificateRequest, you have to go check that
the extension was provided at all. I think that should stay bound to the
CertificateRequest and as a required field.
On Fri, Sep 23, 2016 at 8:35 PM Nick Sullivan
wrote:
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
wrote:
On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov
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 ; David Benjamin <
david...@chromium.org>; Andrei Popov ; Ilari
Liusvaara ; tls@ietf.org
Subject: Re: [TLS] CertficateRequest extension encoding
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, 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
Re: [TLS] CertficateRequest extension encoding
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
wrote:
> On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov
> 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 ; David Benjamin <
>> david...@chromium.org>; Andrei Popov ; Ilari
>> Liusvaara ; tls@ietf.org
>> Subject: Re: [TLS] CertficateRequest extension encoding
>>
>> 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, 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
Re: [TLS] CertficateRequest extension encoding
With this change, we can define multiple matching rules for the same extension
OID, which might be useful. Looks good to me.
Cheers,
Andrei
From: David Benjamin [mailto:david...@chromium.org]
Sent: Thursday, September 22, 2016 6:26 PM
To: Andrei Popov ; Anders Rundgren
; Peter Gutmann ;
Ilari Liusvaara ; tls@ietf.org
Subject: Re: [TLS] CertficateRequest extension encoding
On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov
mailto: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<mailto:anders.rundgren@gmail.com>]
Sent: Tuesday, September 6, 2016 8:36 AM
To: Peter Gutmann
mailto:pgut...@cs.auckland.ac.nz>>; David Benjamin
mailto:david...@chromium.org>>; Andrei Popov
mailto:andrei.po...@microsoft.com>>; Ilari
Liusvaara mailto:ilariliusva...@welho.com>>;
tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] CertficateRequest extension encoding
On 2016-09-06 16:15, Peter Gutmann wrote:
> David Benjamin mailto: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<mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] CertficateRequest extension encoding
On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov
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 ; David Benjamin <
david...@chromium.org>; Andrei Popov ; Ilari
Liusvaara ; tls@ietf.org
Subject: Re: [TLS] CertficateRequest extension encoding
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, 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
Re: [TLS] CertficateRequest extension encoding
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. 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. 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 server provides no guidance, the UI will ask the user, presenting a dialog containing many certificates the user is not aware they have, leading to complete user confusion. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] CertficateRequest extension encoding
> 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...
This is actually a pretty good description of a number of deployments our
customers have. On the other hand, a lot of Web clients can do without
OID-based client cert filtering, so certificate_extensions support is optional
(and if this is not clear, we should fix the language).
> Client-certificates are *extensively* used for secure box-to-box
> communication.
Correct, and this adds to the smorgasborg of client certs.
> 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?
Thanks,
Andrei
-Original Message-
From: Anders Rundgren [mailto:anders.rundgren@gmail.com]
Sent: Tuesday, September 6, 2016 8:36 AM
To: Peter Gutmann ; David Benjamin
; Andrei Popov ; Ilari
Liusvaara ; tls@ietf.org
Subject: Re: [TLS] CertficateRequest extension encoding
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, 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
Re: [TLS] CertficateRequest extension encoding
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, 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
Re: [TLS] CertficateRequest extension encoding
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 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. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] CertficateRequest extension encoding
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 server > to check the certificate is acceptable (as it always is). If we wish to > filter on OIDs, we define, e.g., a key_usage value whose contents have some > KeyUsage-specific meaning. > > > > 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 values, so this should be a relatively small change for them. > But it's OID-specific how the matching works, isn't it? Or are you envisioning that everything but the two exceptions listed here is just going to be an exact contents match? That there were exceptions was what seemed off to me. My gut feeling is exceptions would be the norm and we actually want to be very precise here or we'll just implicitly standardize whatever one PKI library does. (I haven't heard of X.509 extension specs defining matchers.) Doing something TLS-style means we have much clearer semantics. We'd need to do a bit more work defining a bunch of code points for each OID matcher we want, but it's something that ought to be written down anyway. Or is my gut feeling wrong and most of them just an exact match? What is your PKI library's filter interface? (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.) David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] CertficateRequest extension encoding
Ø 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 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 server to check the certificate is acceptable (as it always is). If we wish to filter on OIDs, we define, e.g., a key_usage value whose contents have some KeyUsage-specific meaning. 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 values, so this should be a relatively small change for them. Cheers, Andrei ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] CertficateRequest extension encoding
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 > using OIDs anyway. Concretely: > > 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 server > to check the certificate is acceptable (as it always is). If we wish to > filter on OIDs, we define, e.g., a key_usage value whose contents have some > KeyUsage-specific meaning. > > That would buy us: > > - More consistency with other TLS fields. > > - More compact encoding. (At the cost of going getting to define 2^16 rule > types, but this seems to have been everywhere else.) > > - It is easy to look up what a CertificateExtension means and avoid > conflicts. I can go to the registry and see that type 43 means "match > KeyUsage in this way". For OIDs, it's not obvious whether > For OIDs, it's not obvious whether a given OID has had a matching rule defined. (Existing X.509 extensions do not have TLS-level matching rules defined. I expect new ones will be defined without them too.) > - Relatedly, we can define multiple kinds of matching rules on the same > OID. Suppose we define it one way and we realize we got it wrong. The OID > scheme means we're stuck with it. The TLS-style scheme allows us to define > key_usage_v2 if needed. > > - Less confusion about known OIDs with unknown matching rules. The text is > a little funny right now. There are plenty of known extension OIDs right > now with unknown matching rules. Do we fallback to exact match (which means > we can never change this) or should clients ignore those? That enforcing > known OIDs is a MUST-level requirement makes this messier. > > - More flexibility in defining future rule types. Perhaps we want to say > some extension is not present. Or some rule is really a combination of two > OIDs. Or not an OID at all like "your RSA key must be at least 2048 bits". > > What do folks think? > > David > > On Sun, Sep 4, 2016 at 6:56 AM Ilari Liusvaara > wrote: > >> 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 payload of respective extension in X.509 certifcates? >> Or is it OID-specific (and if it is, what exactly goes to it >> for EKU and KU? RFC 5280 ExtKeyUsageSyntax and KeyUsage?) >> >> >> (Currently the text just refers to DER encoding, and in a >> way that could be read to apply to just to values). >> >> >> -Ilari >> >> ___ >> 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
Re: [TLS] CertficateRequest extension encoding
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 u16s for them. Clients ignore extensions they don't understand, so it is ultimately on the server to check the certificate is acceptable (as it always is). If we wish to filter on OIDs, we define, e.g., a key_usage value whose contents have some KeyUsage-specific meaning. That would buy us: - More consistency with other TLS fields. - More compact encoding. (At the cost of going getting to define 2^16 rule types, but this seems to have been everywhere else.) - It is easy to look up what a CertificateExtension means and avoid conflicts. I can go to the registry and see that type 43 means "match KeyUsage in this way". For OIDs, it's not obvious whether - Relatedly, we can define multiple kinds of matching rules on the same OID. Suppose we define it one way and we realize we got it wrong. The OID scheme means we're stuck with it. The TLS-style scheme allows us to define key_usage_v2 if needed. - Less confusion about known OIDs with unknown matching rules. The text is a little funny right now. There are plenty of known extension OIDs right now with unknown matching rules. Do we fallback to exact match (which means we can never change this) or should clients ignore those? That enforcing known OIDs is a MUST-level requirement makes this messier. - More flexibility in defining future rule types. Perhaps we want to say some extension is not present. Or some rule is really a combination of two OIDs. Or not an OID at all like "your RSA key must be at least 2048 bits". What do folks think? David On Sun, Sep 4, 2016 at 6:56 AM Ilari Liusvaara wrote: > 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 payload of respective extension in X.509 certifcates? > Or is it OID-specific (and if it is, what exactly goes to it > for EKU and KU? RFC 5280 ExtKeyUsageSyntax and KeyUsage?) > > > (Currently the text just refers to DER encoding, and in a > way that could be read to apply to just to values). > > > -Ilari > > ___ > 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] CertficateRequest extension encoding
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 payload of respective extension in X.509 certifcates? Or is it OID-specific (and if it is, what exactly goes to it for EKU and KU? RFC 5280 ExtKeyUsageSyntax and KeyUsage?) (Currently the text just refers to DER encoding, and in a way that could be read to apply to just to values). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
