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.
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. > 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. > 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. --Paul Hoffman _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
