Subject: [TLS] CertficateRequest extension encoding

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 4 Sep 2016 13:56:37 +0300

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

---

From: David Benjamin <[email-masked]>
Date: Sun, 04 Sep 2016 17:41:47 +0000

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 <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: David Benjamin <[email-masked]>
Date: Sun, 04 Sep 2016 17:43:31 +0000

Apologies, I hit 'Send' too early. Finished a sentence below:

> 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.)

---

From: Andrei Popov <[email-masked]>
Date: Mon, 5 Sep 2016 21:46:51 +0000

Ø  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

---

From: David Benjamin <[email-masked]>
Date: Tue, 06 Sep 2016 01:04:33 +0000

On Mon, Sep 5, 2016 at 5:46 PM Andrei Popov <[email-masked]>
wrote:

> Ø  A CertificateExtension is a hint to the client about what kind of
> 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

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 6 Sep 2016 14:15:25 +0000

David Benjamin <[email-masked]> 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.

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 6 Sep 2016 17:36:07 +0200

> 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

---

From: Andrei Popov <[email-masked]>
Date: Tue, 6 Sep 2016 17:03:05 +0000

> 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:[email-masked]] 
Sent: Tuesday, September 6, 2016 8:36 AM
To: Peter Gutmann <[email-masked]>; David Benjamin <[email-masked]>; Andrei Popov <[email-masked]>; Ilari Liusvaara <[email-masked]>; [email-masked]
Subject: Re: [TLS] CertficateRequest extension encoding

On 2016-09-06 16:15, Peter Gutmann wrote:
>> 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.

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

---

From: Geoffrey Keating <[email-masked]>
Date: 06 Sep 2016 11:40:35 -0700

> 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.

---

From: David Benjamin <[email-masked]>
Date: Fri, 23 Sep 2016 01:26:03 +0000

> 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-masked]]
Sent: Tuesday, September 6, 2016 8:36 AM
To: Peter Gutmann <[email-masked]>; David Benjamin <
[email-masked]>; Andrei Popov <[email-masked]>; Ilari
Liusvaara <[email-masked]>; [email-masked]
Subject: Re: [TLS] CertficateRequest extension encoding

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

---

From: Andrei Popov <[email-masked]>
Date: Fri, 23 Sep 2016 21:08:49 +0000

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:[email-masked]]
Sent: Thursday, September 22, 2016 6:26 PM
To: Andrei Popov <[email-masked]>; Anders Rundgren <[email-masked]>; Peter Gutmann <[email-masked]>; Ilari Liusvaara <[email-masked]>; [email-masked]
Subject: Re: [TLS] CertficateRequest extension encoding

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-masked]<mailto:[email-masked]>]
Sent: Tuesday, September 6, 2016 8:36 AM
To: Peter Gutmann <[email-masked]<mailto:[email-masked]>>; David Benjamin <[email-masked]<mailto:[email-masked]>>; Andrei Popov <[email-masked]<mailto:[email-masked]>>; Ilari Liusvaara <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] CertficateRequest extension encoding

On 2016-09-06 16:15, Peter Gutmann wrote:
> David Benjamin <[email-masked]<mailto:[email-masked]>> writes:
>

Anders

> [email-masked]<mailto:[email-masked]>

---

From: Nick Sullivan <[email-masked]>
Date: Sat, 24 Sep 2016 00:35:30 +0000

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-masked]>
wrote:

> 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

---

From: David Benjamin <[email-masked]>
Date: Sat, 24 Sep 2016 00:56:36 +0000

(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 <[email-masked]>
wrote:

David,

     struct {

Nick

What do you think?

David

Thanks,

Andrei

-----Original Message-----
From: Anders Rundgren [mailto:[email-masked]]
Sent: Tuesday, September 6, 2016 8:36 AM
To: Peter Gutmann <[email-masked]>; David Benjamin <

Anders

---

From: Nick Sullivan <[email-masked]>
Date: Sat, 24 Sep 2016 01:17:22 +0000

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 <[email-masked]>
wrote:

>> 1) Move DistinguishedName out of the structure and define it as a
>> TLS-style extension. It's not a required field.
>>>> [email-masked]>; Andrei Popov <[email-masked]>;
>>>> Ilari Liusvaara <[email-masked]>; [email-masked]
>>>> Client-certificates for user authentication on the Web through HTTPS is
>>>> a small and diminishing activity. The decision by the browser vendors

---

From: Martin Thomson <[email-masked]>
Date: Sat, 24 Sep 2016 11:38:53 +1000

On 24 September 2016 at 10:35, Nick Sullivan
<[email-masked]> wrote:
> 2) Remove SignatureScheme from structure, and instead change the behavior of
> the the "signature_algorithms" extension to include all server-supported

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.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 24 Sep 2016 07:23:20 +0300

> 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