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

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

On Feb 5, 2014, at 2:12 PM, Jakob Schlyter <[e-mail]>
 wrote:

> On 5 feb 2014, at 16:17, Osterweil, Eric <[e-mail]> wrote:
> 
>> I noticed that the current (-04?) draft doesn't seem to have taken these recommendations, but I think they should be incorporated.
> 
> As per Paul's reply Jan 8th, we've had no consensus on adding these features as both was (at least by Paul and me) of questionable value. Scott seemed to somewhat agree in a followup mail. However, I do welcome a more elaborate discussion on the pros _and_ cons so we can close these issues.


Hey Jakob,

Indeed, I was adding in support for Scott's proposal because I agreed with at least three of his points.  I'd be happy to elaborate on any of the issues I pointed out, though I did think the comments I initially made were reasonably detailed, no?  Actually, to that point, I don't recall seeing substantive a rebuttal to Scott's suggestions on Jan 8?

I actually did read Paul's response ( http://www.ietf.org/mail-archive/web/dane/current/msg06281.html ), and I felt it didn't present a very in-depth response to the detailed suggestions that Scott made.  That's why I felt it was important to express my support for Scott's suggestions.

For example, Paul responded:
  ``The slight saving of space also introduces a new, significant failure mode …  I'd say "no" on this one.''
I don't agree that this is a failure mode that invalidates the cert learning, and disagree with its dismissal.  Moreover, I elaborated on other reasons why I think these labels are important, ``Finally, I think the `_encr' and `_sign' labels are excellent additions to the _discovery_ mechanism that DANE enables.  Viewing DANE as a discovery mechanism for certs, I can't help but feel that the process of trying to discover a signing key vs.trying to discover an encryption key a first class element of the protocol.  Rather than asking for all keys and then selecting from them, I (as an RP) likely already know which of these I want, and I should be able to discover them separately in DANE (and owners should be able to manage them separately in DANE).  Based on that, these changes really seems like great fodder for being encoded in the domain name, imho.''

Paul also said,
  ``We considered things like this for TLSA, and the WG seemed very hesitant…''
I also don't agree with this, which I noted in my response:  ``difference between saying, `don't use this cert for this operation,' and `this cert is universally revoked.'  These really are fundamentally different, and DANE lets us express them that way.''

I also think Scott's suggestion for the certificate access field is a very good one, and I'd very much like to see his suggested text incorporated.

Eric