Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt

[Viktor Dukhovni <[e-mail]>]

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.

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.

-- 
	Viktor.