On Jan 8, 2014, at 10:54 AM, Paul Hoffman <[email protected]> wrote:
> Thanks for the review, Scott. I didn't see it until I has pulled the lever on > -04 to deal with a few of Mark's comments. > I'd rather hear negative reviews of bad ideas than no reviews of good ones. > On Jan 8, 2014, at 6:58 AM, Scott Rose <[email protected]> wrote: > >> 1. naming convention to help distinguish between signing and encryption key >> certs (for enterprises that use separate certs for encrypting and signing). >> It helps reduce the size of the SMIMEA RRset a bit, but admittedly minor >> compared to the size of an X.509 cert. > > The slight saving of space also introduces a new, significant failure mode, > namely that if the person listing the cert in the DNS gets the type wrong > then the receiver can't use it. I'd say "no" on this one. Admittedly it doesn't save much. > >> 2. a new CU value for "revoked" to indicate that this user's certificates >> have been revoked. > > We considered things like this for TLSA, and the WG seemed very hesitant to > have the DNS be used as a second, unofficial revocation mechanism. For > instance, what would it mean for the DNS to say that an S/MIME cert is > revoked, but when the user pulls a fresh CRL, the cert isn't there? The best > we might do is to have a signal for "go refresh your revocation view" in the > DNS, but that seems like very marginal value. > Our thinking was with local trust anchors where places may not keep their CRL's up to date or even make it available. I hope it's not optimistic in thinking that new DANE uses will encourage people to keep CRL's current. >> There are some signed/encrypted email projects rolling out now that are >> using CERT RR's or combinations of SRV RR's and LDAP servers. Having >> something like SMIME would be an improvement, but the spec needs to be >> finalized. > > And Jakob and I apologize for the long lag since the earlier draft. We too > would like to see this finished. > Count me as a reviewer. Scott > --Paul Hoffman _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
