John Fitton wrote "...if you are going to criticize, then at least offer suggested changes with concrete tangible support for your argument."
OK. One change I could suggest is to divide the APIs into two sets, a High Assurance Consistency subset that supports high assurance that we have technology to implement and a second Extensions set of extensions. The problem with this would be it would divide users into 2 groups, Group 1 who would be certain they cannot make their radio work without the extensions, and a Group 2 who will. Group 2 will use their engineering skills to stay out of the way of the enforcement mechanisms. Group 1 would be free to use the extensions, but it would use their engineering skills to find a way to somehow secure the extensions to the satisfaction of their approver. As a practical matter, approvers have varying backgrounds and some will be harder to convince than others. (I have tried to get a real DAA to contribute to our group.) If there is interest in discussing the details of this (and thats beyond the scope of this email) I think we would eventually conclude that the subset High Assurance Consistency subset would, as a practical matter, boil down to that set of APIs that does not seek to violate the Bell La Padula (BLP) policy (no objects flow up in classification level). Mainly, it would exclude the crypto bypass APIs. The rationale is that that is the widest policy our present COMPUSEC technology can enforce with HA, although there are lots of kinds of policies. In theory, high assurance (HA) could be required for any policy, but as a practical matter, we only know how to enforce one special narrow component of Secrecy Policy, BLP with HA. (Its implementation would end up involving a HW mechanism.) Security Policies are made up of components, and as a practical matter, HA is linked to this component of the policy, if the policy has that component. We simply do not know how to apply HA to banking policies or website policies and others. Consequently practical HA only applies to that one component. There are issues with the interface between the crypto and the modem TRANSEC that need to be addressed separately that may also need to be in a separate subset. I am not convinced that one API approach fits all implementation approaches here. Suggestions to address can be addressed in another email if there is interest in doing any of this. John _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
