>>>>> "VD" == Viktor Dukhovni <[email protected]> writes:
VD> However, once "3 1 x" records are published, there is little point VD> in publishing any other type of record. So I am not sure about VD> the "in addition to" bit. Rather I would suggest "instead of". The idea is that some seem to so wedded to pkix that they feel that they MUST publish 0 or 1 if they publish tlsa at all. (I obviously don't agree with that sentiment; and there is the possiblity that those who do lost interest here and it may not ever be an issue???) Publish both is directed at them, to ease interoperability with any 7250 clients. VD> Once the cost burden (on each server operator) of updating "3 1 x" VD> records is present already, also publishing "2 1 X" just makes VD> things needlessly complex. There is no point. I considered that issue even though I didn't call it out. You're right that it may lead type 2 users to choose between easy updates and supporting 7250 clients. That is part of why I'm only 'becoming convinced'. VD> If the group believes that Postel's rule applies here, and that VD> non-PKIX clients SHOULD always be willing to treat PKIX-EE(1) as VD> DANE-EE(3), then we SHOULD add that to the text the OPS draft, and VD> update the SMTP draft accordingly. Postel's rule goes without writing; even when it isn't mentioned in (potential) standards it remains proper for code to implment it. But I would prefer to see it mentioned in the documents. For a one-way authenticated sockect like tls often is, if the client can create a trust path which /it/ likes, the server's pref doesn't matter. Similarly, when the server authenticates the client, it is only the server's choices about trust paths et alia which should matter to /it/. -JimC -- James Cloos <[email protected]> OpenPGP: 0x997A9F17ED7DAEA6 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
