I can see your point, maybe the client_id will not be in the certificate. If I had an AS I would select to trust one or several CAs and then create certificate mappings between certificate serial number (or some other unique attribute in the certificate) and client_id. If I were to bind a specific certificate to a client_id I lose the flexibility of the PKI (maybe what you want).
I think multiple certificates might not be a uncommon situation especially if you call ASs from different organizations because they will trust different CAs. //Samuel On Thu, Nov 3, 2016 at 5:32 PM, Justin Richer <jric...@mit.edu> wrote: > Jim, > > In those circumstances, are the clients generally calling multiple > different services? Or just one? For those that call multiple services, are > they using multiple (different) client certificates? > > I’m not saying the client would issue its own cert in all cases — much > more common is what I’ve seen, with clients being assigned a certificate > from a trusted CA, and then services that the client talks to being told to > trust that CA and also assign the CN/DN of the cert a set of privileges. > What I *haven’t* seen is a client being issued multiple certificates to > talk to multiple systems. That latter case is common enough in the OAuth > world that I wouldn’t want us to paint ourselves in a corner. > > — Justin > > On Nov 3, 2016, at 10:31 AM, Jim Manico <j...@manicode.com> wrote: > > Thanks Justin. I use several security intel services and they all have > different cert delivery mechanisms for mutual TLS. It's •rare• for services > to let clients choose certs, they are usually assigned to users by each > service from my experience. > > Aloha, > -- > Jim Manico > @Manicode > Secure Coding Education > +1 (808) 652-3805 > > On Nov 3, 2016, at 8:51 AM, Justin Richer <jric...@mit.edu> wrote: > > 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> 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> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
