On Thu, Jan 14, 2016 at 2:25 PM, Rob Austein <s...@hactrn.net> wrote:
> > I would recommend that you think about how any of these proposed > schemes interact with DNS wildcards. Yes, some people use wildcards > with TLSA RRs, or even with CNAME RRs pointing to TLSA RRs: this > allows one to express "every service on machine foo.example.org uses > the same certificate" concisely. > Sure. For client credentials, the most natural use of wildcards I envision would be to specify that a given client uses the same credentials for all application protocols. In our proposed form, this can be accomplished by replacing the leading _app label with a wildcard. Or by aliasing a defined set of per-app names to a generic name. So if one buys George's analysis of this as a role vs protocol > distinction, the question becomes whether it's more useful to be able > to group by roles or by protocols. That is, are you more likely to > want to say "all roles for protocol foo use the same certificate", > "all protocols for role foo use the same certificate", or just not > allow any kind of grouping here at all. The first of these makes the > most sense to me, YMMV. > I assume here that role means a "client", "server" or other role for the same application protocol. We also need to define what protocol means - is it the application protocol or the transport protocol? If considering both independently, we have additional possible groupings. But yes, I agree that making it easy to group the commonly expected ways should be a goal. Assuming the base domain name will be the same in each grouping, "all protocols for role foo" should be expressible with wildcards. "All roles for application protocol Foo" is a bit more challenging, since the client TLSA record uses a symbolic name for the application whereas the server TLSA record uses a port number. Assumptions could be made about applications using well known ports I guess, but that doesn't offer a complete solution. -- Shumon Huque
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
