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

["Osterweil, Eric" <[e-mail]>]

On Feb 5, 2014, at 4:05 PM, Viktor Dukhovni <[e-mail]> 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