Listening in why not allow the certificates to be defined on a regex, and have the queries to the database return a regex match. Seems to solve the problem. Email address grammars more complex than a regular expression seem a pain anyway.
Regards Alexis Shaw b > On 30 Mar 2015, at 4:39 pm, Doug Montgomery <[email protected]> wrote: > > > >> On Sun, Mar 29, 2015 at 2:46 PM, John Levine <[email protected]> wrote: >> In article >> <CAMaMmn=g9FA2sYFzcnLgGCEfpnWFVb3sOwyPMr_g=qhp9az...@mail.gmail.com> you >> write: >> >For any set of aliases that are manually configured, publishing a key, or >> >CNAME for each of those is of the same order of complexity as establishing >> >the alias itself. >> >> For over a decade, I've been doing the common trick of inventing a new >> address each time I sign up for something. Correct me if I'm wrong, but >> you appear to be saying that now, I have to stop, go to some sort of DNS >> provisioning system, tell it about the name I'm about to invent, publish >> the new record, and wait for it to propagate before I can go back to the >> web page where I'm about to use the name. >> >> Also, I have no idea what all of the addresses are that I've made up >> over the years, many of which still get mail from whoever I gave them >> to. It appears I'm out of luck there. > > I am not sure I understand the use case of wanting to enable opportunistic > inbound encryption to all of the thousands of address that you can't even > remember. But OK, is your use case is that you want keying (the same > keying?) for all 500M potential variants? .... or just the thousands you have > used? > > What about the person who might want different keying for his personal email > and that of his mailing lists (assuming that is what many folks do with their > aliases). > > Actually there are strict compliance implications about managing network > identities in many commercial environments, where the idea that on is > creating keying material for other, non explicitly created identities, won't > fly. So if you enable key discovery and retrieval the 500M variants, please > provide a mechanism to explicitly disable this feature too. > > As for DNS provisioning, none of this is going anywhere if there isn't > significant automation between identity creation and keying. The vast > majority of users don't even know there is a DNS. > > Personally, I am interested in enterprise-class solutions. Here if the DANE > keying material is not dynamically updated from our identity/credential > management system, it is a complete non-starter. > >> >> >Unless your user agent generates a fuzzy match variant of your from: >> >address outbound with each email, I am not sure that the scaling problem is. >> >> There are plenty of mail systems that do that. Perhaps it would be >> helpful to learn more about the way that modern mail systems work. > > I am aware of how mail modern systems work (many have better ways of > organizing email than generating thousands of addresses :). I was speaking > of the hypothetical 500M algorithmic variants. I assume your mail system is > not randomly generating your thousands of aliases. > > I am also aware of the problem I thought we were trying to solve. What I > heard at the mic was that solving the general problem of keying that matches > all the various local fuzzy matching rules of modern mail systems was either > intractable, or outside the scope of DANE, or both. Let alone taking on the > problem of those who don't want that behavior, or might want different keys > on different local aliases. > > What I heard after the meeting on the list was some support of solving the > simple problem in a ubiquitous way in DANE. I am guessing we would provide > a solution that covers the vast majority of users with a simple one key per > unique LHS. > > I think there may be support for solving the simple problem in DANE now. > > As for the more complex scenarios, it might warrant revisiting the use cases > to understand the requirements, design trade offs of if, where and how the > issue is addressed. > >> >> R's, >> John > > > > -- > DougM at Work > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
