+1 for “tls_client_auth_root_dn" On making it an array, I think that adds complexity for little gain, and perhaps introduces new trust issues.
I think it should be one trusted root or all the trusted roots. If you only trust 5 then configure that in the AS. An array seems only useful where the client has a cert from x but may want to get the next one from y and not re-register. I think if the client or federation operator is locking itself down to specific issuers one per client should be fine. I expect that in most cases the issuer will need to be in the trust store of the AS anyway so this is just pinning the cert to one of a limited set. John B. > On May 15, 2017, at 2:42 PM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > I'll add text/clarification that the DN metadata fields being RFC4514 string > representations of DNs in the next draft. > > Given that this is a profile of use and the metadata fields are just one way > to express the binding of certificate and client, and after thinking about it > some more and not wanting to introduce too many variations, I feel that > keeping tls_client_auth_subject_dn as the subject distinguished name of the > client certificate is more straightforward and sufficient for this case. > > Is there rough consensus to change "tls_client_auth_issuer_dn" to > "tls_client_auth_root_dn" as was suggested? The latter name makes sense to me > but I don't want to make that change without a little more input or buy-in > from the WG. So please respond one way or the other, if you've got an > opinion. > > Similarly I'm looking for some rough consensus around if a single root/issuer > is sufficient in the metadata before potentially making any changes. Should > "tls_client_auth_issuer/root_dn" remain a single DN string value or should it > be an array allowing for more than one? > > > > On Fri, Apr 21, 2017 at 6:18 PM, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> wrote: > I agree with Brian. > > Trying to do anything with PKIX opens up cans of worms. One of the reasons > we have resisted to this point. > > However there are server to server use cases that legitimately need this. > > I agree that in general DN is a mess, I suspect that telling people to > directly use the DER encoded version wont fly, so my thought was to use the > RFC 4514 string representation that most tools produce. > > We did talk about subject alt DNS Names, however those may not be present in > eIDAS certificates that some people may need to use for legal reasons, or if > it is present it might be an email. > > I suspect that users of this will fall into two camps. One that has a small > set of trusted CA that are configured out of band and any certificate from > those roots with the correct DN is OK. > > The other group will be trying to do something more dynamic with SSL server > certs (May or may not be EV) I could see those people preferring DNS Name > subject alt, or using JWKS to publish there certs. > > The problem is finding the right balance of flexibility without too many > options to confuse people. > > I am inclined towards DN for those that are willing to suffer the pain, and > JWKS_uri for everyone else. One advantage of the JWKS_URI approach is that > self signed certs should work just fine, that is something that the R&E > people will want if they use this. > > For most proof of possession we should be promoting token binding as the most > flexible approach as it also works with mobile without per instance > registration. > > John B. > > >> On Apr 21, 2017, at 7:41 PM, Brian Campbell <bcampb...@pingidentity.com >> <mailto:bcampb...@pingidentity.com>> wrote: >> >> Thanks, James, for the adoption support as well as the review and comments. >> I've tried to respond to the comments inline below. >> >> On Thu, Apr 20, 2017 at 11:33 PM, Manger, James >> <james.h.man...@team.telstra.com <mailto:james.h.man...@team.telstra.com>> >> wrote: >> I support adoption of draft-campbell-oauth-mtls. >> >> Now some comments on the doc: >> >> 1. [§2.3] The syntax of tls_client_auth_subject_dn is not specified. Perhaps >> LDAP's "String Representation of Distinguished Names" [RFC4514]? Perhaps a >> base64url-encoding of a DER-encoded DN? It would actually be better to allow >> any subjectAltName to be specified, instead of a DN. >> >> How about calling it tls_client_auth_subject and defining it as a string and >> allowing it to represent the expected subject which could be in the cert as >> the subject DN or a subjectAltName? For Subject DN and DN subjectAltNames it >> would be the "String Representation of Distinguished Names" and an >> appropriate string for the other subjectAltName types (I'll have to look at >> what's there 'cause I don't know off hand and guidance or suggested text is >> always more than welcome). >> >> >> >> >> 2. [§2.3] Change the name of tls_client_auth_issuer_dn (maybe >> tls_client_auth_root_dn). Given tls_client_auth_client_dn, it will be too >> easy to assume this pair refer to the issuer and subject fields of the cert. >> >> The accompanying text tries to make it clear that it's the root issuer but >> the tls_client_auth_issuer_dn name can certainly be changed to >> tls_client_auth_root_dn or something along those lines, if folks think the >> name in -01 is liable to cause confusion? >> >> >> >> PKI chains can be complex so the expected root might not be such a stable >> concept. For example, the Let's Encrypt CA chains to an ISRG Root and an >> IdenTrust DST Root [https://letsencrypt.org/certificates/ >> <https://letsencrypt.org/certificates/>]. >> >> The goal was to provide a metadata field to express some constraint for what >> is kind of expected to be a common deployment of a number of entities >> participating in some OAuth API thing and are being issued certificates from >> a common issuer for the group of participants. >> >> Perhaps it should be an array of strings rather than a single value? >> >> Or do you have suggestions for some alternative? >> >> >> >> >> 3. [§2.3] If a client dynamically registers a "jwks_uri" does this mean the >> authz server MUST automatically cope when the client updates the key(s) it >> publishes there? >> >> If the authz server supports that kind of trust model as well as dynamically >> registration, then I would expect so, yes. >> >> >> >> >> 4. [§3] An access token is bound to a specific client certificate. That is >> probably ok, but does mean all access tokens die when the client updates >> their certificate (which could be every 2 months if using Let's Encrypt). >> This at least warrants a paragraph in the Security Considerations. >> >> In my own mind that was implied and okay because it's likely that access >> tokens will have a shorter lifespan than certificates and refreshing or >> getting a new access token is typically easy anyhow. >> >> Anyway, it doesn't hurt to be explicit about it, can you propose some such >> text for the Security Considerations? >> >> >> >> >> 5. [§3.1] "exp" and "nbf" values in the example need to be numbers, not >> strings (drop the quotes). >> >> Silly mistake on my part. Thanks for catching that. Will fix. >> >> >> >> 6. An access token linked to a client TLS cert isn't a bearer token. The >> spec should really define a new token_type for responses from the token >> endpoint. That might not necessarily mean we needs a new HTTP authentication >> scheme as well (it might just hint that "Bearer" wasn't quite the right >> name). >> >> Indeed "Bearer" isn't quite right and very likely a name that would be >> different with the benefit of hindsight. But other than having names on the >> wire that are more true to the nature of the tokens, I don't know that a new >> token_type or HTTP auth scheme adds value to the use cases here. However, >> they would likely make deployment of this stuff more cumbersome and take >> longer. Whereas many systems can likely plug in mutual TLS on top of the >> existing token_type and HTTP auth scheme without major changes. I'm strongly >> inclined to not introduce a new token_type and more inclined to not do a new >> HTTP auth scheme. >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
