>>>>> "VD" == Viktor Dukhovni <[email protected]> writes:
VD> Indeed I was/am expecting some TLS implementations to automatically VD> negotiate RPK and use keys extracted from the leaf certificate (far VD> simpler in mixed environments than configuring separate bare SPKI VD> objects). I tend to expect crypto authors to be more conservative in enabling new extensions by default. Heartbleed, of course, demonstrates that such conservatism isn't always there.... If it does get added to the libs enabled by default, w/o the need for application buy in, things will be radically different than what I expected. VD> I am planning to *recommend* a server BCP of "make sure each and VD> every U/S/M matches a current keyset" strategy anyway, there are VD> non-RPK reasons to do that anyway. Such a recomendation is most welcome. VD> So the question with respect to RPK is whether it is: VD> * The server's responsibility to carefully publish TLSA records VD> in such a way that no U/S/M subset is purely past/future, also VD> closing the exposure. That would be my preference. VD> If the consensus is that PRK enablement in server applications VD> needs to be explicit, and it needs to be off by default, I wasn't advocating either way. Just anticipating that lib and app authors would be conservative about the new extension. And I doubt any will care whether an rfc demands by default or only when configured. -JimC -- James Cloos <[email protected]> OpenPGP: 0x997A9F17ED7DAEA6 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
