Re: [dane] draft-ietf-dane-smime and certificate discovery

[Viktor Dukhovni <[e-mail]>]

On Wed, Feb 05, 2014 at 03:29:29PM -0800, Paul Hoffman wrote:

> So, WG: is "DNS for delivery vs. DNS for delivery and discovery"
> a topic people want to revisit?

Since I am relatively new here, I'll ask:  What is the distinction?

My best guess is:

    - Discovery, one time lookup of data that is retained indefinitely
      and refreshed infrequently, in particular potentially beyond
      the shorter of the DNS TTL and the RRSIG expiration.

    - Delivery, lookup as needed with optional caching bounded by
      the shorter of the record TTL, the RRSIG expiration and any
      applicable local policy.

Is that about right?  If so, since TLSA in an online protocol, it
seems clear that TLSA should be "delivery".

For SMIMEA, the case is a bit less clear-cut.  Whenever one is
capable of receiving new email one is presumably online, and so
receipt of associated SMIMEA records should be feasible.  When
composing encrypted replies one would often, but not always have
a cached copy of the sender's encryption cert and one may not be
online.  

The MUA could defer the encryption step until it is back online,
but then an unencrypted copy of the message sits in the local outbox
until network connectivity is restored.  Otherwise, the user would
have to accept the risk that the most recently cached cert is no
longer valid (no way to check SMIME for a revocation either).

I don't see much of a role for SMIMEA revocations in either case.
Any time one can look-up a blacklist one can lookup a (possibly
empty) whitelist instead.

So it is not clear how "discovery" is a better protocol than
delivery.  Feels like printed credit card black-lists in the 70's
before credit card verification went online.

-- 
	Viktor.