Yes, I elided the certificate issuance process. The point remains the
same: you're not going to be submitting a CSR to the same party you're
getting your client_id from, usually. If the draft assumes that, then
it's incredibly limiting.
Do people really use separate TLS client certs for separate connections
in the wild? I've personally never seen that. What I've seen is that a
piece of software gets its certificate that it uses to make whatever
connections it needs to make.
-- Justin
On 11/3/2016 8:48 AM, Jim Manico wrote:
Just to be clear, the relationship should more like...
AS issues public key to clients, or client sends public key to AS. The
authorities job is NOT to give the client the public key, but to sign
the public key for authenticity. It's bad practice to accept the full
cert (pub key+signature) from an authority. If an authority is
creating your public key, they are also creating your private key.... bad.
> The client will use the same cert across multiple connections,
possibly multiple AS's, but the same isn't true of the client_id.
This seems like a bad idea. I suggest a separate key/signature for
each service.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805
On Nov 3, 2016, at 8:41 AM, Justin Richer <jric...@mit.edu
<mailto:jric...@mit.edu>> wrote:
I agree that the client_id is unlikely to be found inside the
certificate itself. The client_id is issued by the authorization
server for the client to use at that single AS. The certificate is
issued by the CA for the client to use on any connection. The AS and
CA are not likely to be the same system in most deployments. The
client will use the same cert across multiple connections, possibly
multiple AS's, but the same isn't true of the client_id.
Additionally, I think we want to allow for a binding of a self-signed
certificate using dynamic registration, much the way that we already
allow binding of a client-generated JWK today.
I do think that more examples and guidance are warranted, though, to
help AS developers.
-- Justin
On 11/2/2016 5:03 PM, Brian Campbell wrote:
On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <sam...@erdtman.se
<mailto:sam...@erdtman.se>> wrote:
I agree it is written so that the connection to the certificate
is implicitly required but I think it would be better if it was
explicit written since the lack of a connection would result in
a potential security hole.
That's fair. I agree it can be made more explicit and that it be
good to do so.
When it comes to the client_id I think subject common name or
maybe subject serial numbers will be the common location, and I
think an example would be valuable.
In my experience and the way we built support for mutual TLS OAuth
client auth the client_id value does not appear in the certificate
anywhere. I'm not saying it can't happen but don't think it's
particularly common.
I can look at adding some examples, if there's some consensus that
they'd be useful and this document moves forward.
I´m not saying it is a bad Idea just that I would prefer if it
was not a MUST.
With very limited addition of code it is just as easy to get the
certificate attribute for client id as it is to get it from the
HTTP request data (at least in java). I also think that with the
requirement to match the incoming certificate in some way one
has to read out the certificate that was used to establish the
connection to do some kind of matching.
Getting data out of the certificate isn't a concern. I just believe
that the constancy of having the client id parameter is worth the
potential small amount duplicate data in some cases. It's just a -00
draft though and if the WG wants to proceed with this document, we
seek further input and work towards some consensus.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
