On Wed, Dec 16, 2015 at 1:22 AM, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: > On Mon, Dec 14, 2015 at 8:04 AM, Jari Arkko <jari.arkko@xxxxxxxxx> wrote: > That is why consequences are important. A tenfold increase in > data volume is a serious consequence and should be accepted as > justification for a red line. The fact that the browser market is > driven by competition to optimize page load latency gives > rise to consequences. > > In general, a red line is not a personal constraint, it is an external one. Another way to identify a genuine red line from a bluff is what happens afterwards. Right now we have a situation in which CABForum rules for managing the WebPKI deliberately and intentionally violate a MUST in RFC 5280 Sec 4.2.1.10. According to RFC 5280, a name constraint MUST be marked critical. The industry explicitly rejected that approach and the CABForum has an override that allows the CA to decide. This is not an abstract dispute, conforming with RFC5280 causes a lot of real world systems to break which is of course the sole point of the critical flag. The only reason for marking an extension critical is when the desired behavior is for relying parties that do not understand the extension to reject the certificate. The industry has decided that wherever possible, name constraints should be used to limit the exposure of a CA or intermediate in the case of breach or compromise. Marking the certificates critical would have rendered them unacceptable. There has been one positive outcome from the situation though. I did use it in a private discussion with a former senior NSA employee as an example of an instance where the disclosure of the NSA BULLRUN program has materially damaged cyber security efforts. That person has subsequently changed their position on crypto backdoors to oppose them. Even if it is the case that the opposition was not driven by a covert NSA program, the suspicion that it might be is obviously damaging and corrosive. My personal theory is that that particular set of slides was actually written by a Major trying to make Colonel who was trying to explain how his cyber-defense activities fit into a mandate for cyber-attack. I think that there is a need for some mechanism to correct the situation in cases like these where a group in IETF came to a particular decision and the actual users of the specification came to a different decision and acted on it. No useful purpose is served by insisting that the specification reflect a Working Group consensus that has been rejected in the defacto Industry standard. More generally, I see a rather important distinction between 'the consensus is that we shall all do X' and 'the consensus is that you must do X'. There is a particular style of 'consensus based' standards making where a small group decide what they want to do and then use some very sharp elbows to eliminate folk who might have a different idea from the conversation. This is a particular problem with some of the people who peddle consulting in 'IETF process' and whose metric for success is speed to get their client's proposal published as an RFC rather than establishing the industry support necessary to get the proposal widely used.