On 03/11/16 19:11, Sergey Beryozkin wrote: > Hi > > In our implementation we support the following scenario: > - the client registers its public certificate during the client > registration
Did you extend the standard client reg API for this purpose? How does the cert registration actually take place? > > - next, mutual/two-way TLS is used, so AccessTokenService tries to > figure out the client_id. At the moment it assumes the client_id is > (Java) X509Certificate.getSubjectX500Principal().getName(). > > Next it retrieves a client with this name and compares the TLS > client/peer certificate against the pre-registered one. > > I think it may be interesting to explore further if client_id can > become optional based on what Samuel said. > > For example, indeed I can see how I can update our code to have a > mapping between some of client certificate's properties and a client > id stored within a Client registration. > > The question is how to find a given Client registration effectively > given only a certificate, without an optional client_id. One would > need to have a map between these client certificate attribute and > client_id or Clients. > > Cheers, Sergey > > > > On 03/11/16 16:48, Samuel Erdtman wrote: >> 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 >> <mailto: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 >>> <mailto: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 <tel:%2B1%20%28808%29%20652-3805> >>> >>> On Nov 3, 2016, at 8:51 AM, Justin Richer <jric...@mit.edu >>> <mailto: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 <tel:%2B1%20%28808%29%20652-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 <mailto:OAuth@ietf.org> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > -- Vladimir Dzhuvinov :: vladi...@connect2id.com
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
