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
