A common thread I am seeing is we are not doing enough to prove\document we can robustly test something.
A lot of the web pki ops workgroup was spent discussing the fact we don't have good test tools for pki certificate validation. Likewise I have seen the case made that implicit tls negotiation is more successful then explicit tls negation because it is easier to test. We define what features must or should be supported but leave it up to the reader on what tests are necessary to prove the implementation is robust and trustworthy. That seems an omission. We are building a threat model which should document all the way we can be attacked. We should then be able to lists all the tests necessary for a rfc to prove an attacker would not succeed. Given this would change over time as we learn more threats, it would make sense to have this as a separate draft much like we split out cryptographic algorithm requirements from protocol drafts. Trevor
_______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
