On Tue, Mar 05, 2013 at 05:29:18PM -0500, Andrew Sullivan wrote:
> > We can attempt to more completely mimmic legacy public CA PKI
> > certificate validation and remove the choice I advocate, but that
> > would be unfortunate, since it would needlessly only serve to limit
> > the choices available to domain owners.
>
> It's not needless. It's part of the design of this feature.
If the meaning of the design is not crystal clear in the RFC (e.g.
the dane-srv draft misread 6698 at least in part), and I am
challenging the rationale used to justify a putative interpretation,
telling me that is so by design merely begs the question.
The feature (certificate usage "1") gives the domain owner a
mechanism to express a policy preference for PKIX validation
constrained to a given EE certificate. The name check part of this
policy can and should be carried out by the domain owner statically
before the TLSA RR is signed (if that's what the domain owner
intends).
Why delegate this (ostensibly important to the domain owner) policy
check to the client, if it can be performed exactly once when the
TLSA RR is about to be generated?
A substantive answer would explain why static name checks by the
domain owner are insufficient and why it is better to defer the
static checks in favour of dynamic checks by clients.
Such a subtantive answer should take into account evidence to the
effect that static-only checks support use-cases not supported by
dynamic checks with no detriment to the use-cases in which static
and dynamic checks are functionally equivalent (provided clients
never fail to carry out the dynamic checks).
I think that section 4 of 6698 should be clarified to explain
where name checks are appropriate and *who* should carry them
out. I further posit that for 1/3 usage the *who* in question
is the domain owner alone. If the working group does not agree
with this analysis on logical grounds, please tell me why.
If you concede my point, but the standard is set in stone and
sufficiently clear on this point, and it is too late to clarify or
amend, fine there are other imperfect standards.
The only reason I'm tilting at this windmill is that it seems
that the standard is not yet clear, and it could be clarified
in a more fruitful direction.
In addition the implementation of the standard in Postfix would be
more natural if all a priori given EE certificates were treated
identically with regard to name checks. Check that we have the
right cert because either we knew which one to expect (1/3), or
because the CA provided a name binding (0/2).
The interpretation presented by Andrew and others asks for a hybrid
model, which I am loathe to implement. It does not pass:
- Don't fail when you can succeed.
- Don't do dynamically what can be cheaply+reliably done statically.
If there is still any opportunity to reconsider the issue, please
examine my suggested interpretation on its merit.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
