I may not be completely up to date in this discussion, However, RFC 6125 <https://tools.ietf.org/html/rfc6125#section-6> "In general, *this specification recommends and prefers* use of subjectAltName entries (DNS-ID, SRV-ID, URI-ID, etc.) over use of the subject field (CN-ID) where possible, as more completely described in the following sections. However, specifications that reuse this one can legitimately encourage continued support for the CN-ID identifier type if they have good reasons to do so, such as backward compatibility with deployed infrastructure (see, for example, [EV-CERTS])."
And I believe this is the more common practice. https://security.stackexchange.com/questions/175786/is-it-required-to-have-the-same-domain-name-and-common-name-for-ssl-certificate/175788#175788 -- -jim Jim Willeke On Thu, Apr 4, 2019 at 4:55 PM Filip Skokan <panva...@gmail.com> wrote: > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
