> Ok. To me this sounds like you need a more complex^wsophisticated > client identification mechansim than what a plain cert-to-name gives > you.
I wouldn't characterize it as such. It's not complex. It's a simple thing, optimizing the trivial case for improved usability. I'm unfamiliar with how all other models might use cert-to-name, though one use is here [1], but I imagine all uses that are associated with a TLS connection also wishing for this optimization (this includes [1]). For models that are not associated with a TLS connection, the current cert-to-name 'mandatory true' is just fine. [1] https://tools.ietf.org/html/rfc7407#section-2.12 <https://tools.ietf.org/html/rfc7407#section-2.12> > I don't think there is anything wrong with the current > cert-to-name grouping. See above. > So let's continue this discussion in the > netconf ML, where this model is being developed. I'll fork this part of the conversation there. Kent // contributor
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
