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