On Feb 5, 2014, at 4:05 PM, Viktor Dukhovni <[email protected]> wrote:
> On Wed, Jan 08, 2014 at 07:54:26AM -0800, Paul Hoffman wrote: > >>> 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. > > I strongly support Paul's comment. Unlike stale on-disk certificates > held by third-parties, published DANE records (SMIMEA, TLSA, ...) > are maintained by the subject's domain and can be presumed *current* > when the publishing domain is not negligent. > > Therefore, there is no need for a fragile blacklist mechanism. > The DANE data in DNSSEC is a comprehensive whitelist. Every > certificate not listed in DANE is the wrong certificate, unlike > CRLs DANE fails closed. Hey Viktor, So, I worry that this relies on implicit assumptions being made about processing being done on the MUA (RP) side. If something is not available in DNS, does that mean I shouldn't use a cert I may already have in hand, I shouldn't fall back to AD, I shouldn't use a previously seen value, etc… How do I know the domain was ever serving SMIMEA if there is nothing in there now? I suppose we could conflate deauthorization of certs with revocation of certs. However, I was suggesting that we _could_ use this opportunity to express an unambiguous piece of evidence that clients should use SMIMEA-processing, and should _not_ use a specific cert (even though it may not be universally revoked). > When the DANE associated data published for a user is a CA that > signs multiple EE certs and a particular user's keys need to be > revoked, the simplest solution is to publish an EE association for > that user until the revoked certificate expires. Either way there > is a special EE DANE record for the user in question, but one or > more valid EE certs are more useful than a list of invalid EE certs. As I think you said above, ``DANE records (SMIMEA, TLSA, …) are maintained by the subject's domain and can be presumed *current* when the publishing domain is not negligent.'' I think it's a nice option to give DNS provisioning systems to set a flag in an RR that deauthorizes a cert w/o having to have the CA issue a new association. Perhaps I'm off here, but it seems far more complicated from an operational perspective to have to hop through a CA and get something issued in order to deauthorize a cert rather than just updating the RR, no? Eric _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
