> Am 02.04.2015 um 17:08 schrieb Osterweil, Eric <[email protected]>: > > > On Apr 2, 2015, at 10:23 AM, Olafur Gudmundsson <[email protected]> wrote: > >> <chair-hat on> >> The drafts will be advanced with the same lookup mechanism. >> The process is defined in OPENPGP draft, the SMIME draft will follow OPENPGP >> lead in email address “transformation”. > > Hey all, > > As a clarifying side comment (to the hashing algo): there is still some > interest in having _encr and _sign labels in the SMIMEA RR’s lookup name. > imho, this can offer a lot of benefits in managing user preference when > looking up the association between a mailbox and crypto material. I only > mention that because I think this could be seen as part of the ``lookup > mechanism.’’ > > libsmaug uses these labels (as well as our soon-to-be available provisioning > portal).
Just a question for ._encr and ._sign: Do you really plan to store private keys in public DNS? Is it, what ._sign will be used for? Isn’t this really a security issue? I am not a DNS expert, but isn’t it possible to walk through a DNS zone using NSEC and get all records of a zone and therefor you also would get all private keys in the subdomain ._sign? I personally only would store public keys in DNS for opportunistic encryption. Therefor I would not see a need for an extra subdomain ._encr (and of course not ._sign) Christian -- Bachelor of Science Informatik Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
