Yes. S pozdravem, *Filip Skokan*
On Thu, 4 Apr 2019 at 22:36, Justin Richer <jric...@mit.edu> wrote: > Thank you, I did miss that text. This should be called out more explicitly > in §2.1, perhaps by specifying that it is only one field. This still > doesn’t set precedence, but it implies that it’s an error for a client to > have more than one field set of the available options. Is that your read on > this as well? > > — Justin > > On Apr 4, 2019, at 4:23 PM, Filip Skokan <panva...@gmail.com> wrote: > > Justin, I had the exact same question off list and believe draft 13 > clarified this. > > https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-2.1.2 > > A client using the "tls_client_auth" authentication method MUST use > exactly one of the below metadata parameters to indicate the certificate > subject value that the authorization server is to expect when > authenticating the respective client. > > Then it lists the different dn/san properties. > > S pozdravem, > *Filip Skokan* > > > On Thu, 4 Apr 2019 at 22:20, Justin Richer <jric...@mit.edu> wrote: > >> We’ve just started implementation of SAN-based certificate >> authentication, based on the changes in version -13 of the draft. I believe >> this addition is a bit unclear, due to it being added so late in the >> document process. >> >> My question is how does an AS determine whether to DN or SAN for >> certificate checking? Corollary, are these mutually exclusive or can they >> be used together? Currently, the specification text lists DN and SAN as an >> “or” with no indication whether this is an inclusive or exclusive “or”, and >> what to do when there’s overlap. >> >> This has implications both for the implementation of the server >> processing the request as well as the client metadata model, since the >> client fields are all in parallel to each other. I can see a few ways of >> handling this. >> >> >> 1) One of the fields takes precedence over the other. Say for example you >> choose the DN field: if it’s set, then you do DN matching and ignore the >> SAN fields entirely, both in the cert and in the client’s registration. >> Inverse is true if you choose the SAN fields over the DN but the principle >> is the same. We should be explicit if there’s an intended precedence >> between these two, and even more explicit if the DN and SAN are at equal >> level and the AS gets to choose. We also need to be clear if it’s an error >> condition if both are set simultaneously, like the way that jwks and >> jwks_uri are mutually exclusive. >> 2) You set an explicit switch in your client model that says whether to >> use the DN or the SAN fields in comparison, and your code branches based on >> that to either DN or SAN processing. This could also be added as an >> explicit client metadata field, or it could be an internal detail. If an >> internal detail, we should be explicit about there not being a predefined >> precedence between the fields. >> 3) If it’s allowable to use them together, you match everything that’s >> set in the client, and at least one field MUST be set. >> >> >> What’s the intended behavior for implementers, and should we be more >> explicit about this? We are starting our implementation with (1) pending >> the outcome of this thread, and I’d be curious to know how others are >> implementing this in their systems. >> >> Thanks, >> — Justin >> >> _______________________________________________ >> 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
