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

[Viktor Dukhovni <[e-mail]>]

On Wed, Feb 05, 2014 at 09:30:34PM +0000, Osterweil, Eric wrote:

> 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).

Well if the DNS is not available, you won't see the DNS revocation
either.  So I think you're imagining a situation were a client is
often disconnected, and caches certificates.

In that case, I would suggest the following strategy for an SMIMEA
capable MUA:

    Each signed message received by the MUA is initially in an
    unknown verificaiton state.  When an SMIMEA lookup is successful,
    and returns a usable certificate the message is marked permanently
    valid (certificate valid at time of message receipt).  The
    certificate can be cached for the shortest of the TTL of the
    SMIMEA RRset, the RRSIG expiration time and a configurable
    local cache limit (suggested default 7 days).

    Each new message received generates a new background attempt
    to determine the SMIMEA records, but if cached data is available,
    a cached certificate can be used (lies within RRSIG lifetime).

    Likewise, outgoing mail can be encrypted to a cached certificate
    only within its DNSSEC validity interval, but otherwise requires
    a new SMIMEA lookup.

Basically the MUA operates with a stored (rather than in-memory)
DANE RRset cache.

> > 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?

I don't see any reason to de-authorize by publishing a blacklist,
when one can just simply stop publishing the record or replace a
TA record with an EE record.

-- 
	Viktor.