Thank you very much for your quick reply! > I think it’s great that you’re looking this! To answer your specific > question, I understand that different people have differing levels of > interest in signing vs. encryption (vs. both) for email. I recall a number > of us had discussions about how you could place a root certificate at a > wildcard at the mail domain’s APEX, so querying any lhs under that domain > would return an SMIMEA record that could be usage type 0 or 2 (PKIX_TA or > DANE_TA). I think that would accomplish your goal of not needed to key every > user. > > So, for [email protected] <mailto:[email protected]> through > [email protected] <mailto:[email protected]> , you would hit *.example.edu > <http://example.edu/> SMIMEA, which would return the root cert. Does that > make sense?
Yes, that absolutely makes sense. However, I wonder if that is intended use, and if so, I suggest that it should absolutely be mentioned in the RFC. > Just as some context: we, in my lab, are looking into SMIMEA as well and > we’ve launched a pilot of an open provisioning infrastructure for managing > per-user complexities, MUA add-ons that use DANE for S/MIME, and an open > reference implementation of several DANE protocols (DANEportal.net > <http://daneportal.net/> , kurer.daneportal.net > <http://kurer.daneportal.net/> , and libCanute, respectively). Our goals > seem a little different than yours, but would be happy to see if they can > help you out. We presented at the last IEPG, and the students are (I > believe) on this list and can respond if you have any other thought! Looks very interesting, and I appreciate any exchange of ideas and concepts. I welcome anything that could help to simplify S/MIME encryption for end users! Let's stay in touch. Thankls Metin
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
