On Wed, Jun 04, 2014 at 03:48:36AM -0400, James Cloos wrote:
> I just occurred to me that, given that oob is negotiated bewteen the
> client and the server, that the oob concept is !pkix, and any
> verification of the spki is conceptually identical, a tlsa 11x is just
> as usable by an oob client as a 31x is.
This is a slippery slope. In my original SMTP draft I had language
suggesting aumatic mapping PKIX-TA(0)->DANE-TA(2) and
PKIX-EE(1)->DANE-EE(3). This was abandoned in favour of 0/1
undefined (likely "unusable") for SMTP and only 2/3 supported.
If the server operator wants PKIX checks, client-side overrides
should probably not be an RFC-defined behaviour.
Now it turns out that Postfix treats "0" as "unusable", but indeed
automatically maps "1" to "3", because as you observe "why not?".
However, I think such liberties should not be officially endorsed.
> It does not matter than a typical full cert client would do a pkix
> verification on top of the tlsa verification when the tlsa is 11x.
> The oob client *and server* have agreed not to bother with pkix,
> so any ee-spki association is sufficient to verify the offerred spki.
It would be better for such servers to publish "311" and be done.
> In other words, by agreeing to oob, the server gives the client consent
> to ignore any pki details about the verification.
> Only tlsa 0 and 2, which do not dirrectly reference the ee, are really
> unusable in the oob case.
> So the proper language probably is something like:
>
> End-Entity SPKI association
>
> via dane, ldap, firmare or any other pre-agreed method.
If the WG collectively agree that non-PKIX clients are free to map
PKIX-EE(1) to DANE-EE(3) and that server operators can expect this
behaviour, then we still have time to ammend the SMTP draft, to
say that PKIX-EE(1) may be published but SHALL be treated as though
it were DANE-EE(3) by SMTP clients.
My view at this juncture is that such mappings should not be
expected, and are a matter of client implementation discretion.
If a client views PKIX-EE(1)/SPKI(1) as though it were DANE-EE(3)/SPKI(1)
then, that client obviously won't see any "oob" obstacles from any
associated RRs (of course PKIX-EE(1)/Cert(0) is still a potential
problem, barring new constraints the records servers should publish).
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
