On Fri, Jun 06, 2014 at 11:25:26AM -0400, Paul Wouters wrote:
> On Fri, 6 Jun 2014, Viktor Dukhovni wrote:
>
> >You'll find that there is little support for RPK formats other than
> >"3 1 X", despite a small number of suggestions to the contrary. A
> >consensus around "3 1 X" is I think a safe bet.
A safe bet that this becomes the standard encoding of RPK TLSA records.
> It is not a safe bet. We only need one external requirement, like PCI-DSS
> or the EV consortium to start dictating one has to publish and match a
> full certificate to get their goodies like a green url bar.
Which little bearing on how to publish the RPK records.
> Then you
> would need a mix of TLSA types to support both the PKIX/CABforum/EV
> universe and raw public keys.
Encoded as "3 1 X" which was the limited scope of that comment.
> And by not allowing that, or by stating
> a mixed TLSA RRset means sacrificing raw public keys, the result would
> force everyone to be stuck with full PKIX validation.
That's a separate question than the one under discussion. The
hypothetical seems rather conspiratorial. In a conspiracy more
likely these various actors, if they were acting to thwart DANE
adoption, would simply erect barriers to all use of DANE TLSA.
(Perhaps they're doing that already). Just preventing use of RPK
seems like a rather modest goal if DANE "3 0 1" and "2 0 1" are
are left standing and become popular.
You can at least relax in my case, I am not part of any X.509
cospiracy. :-) Rather, I just work to be sure that things actually
work in all cases, including the corner ones.
> In other words, your 'optimization' can be harmful. You're still welcome
> to code that into your software. But you can't standardize it.
Just to be clear I see RPK as an optimization, and my suggested
suppression of RPM with mixed TLSA RRs as forgoing the optimization.
However, we should tackle this point in the new thread I started,
after refocusing the arguement, it seems to be making better
progress.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
