WARNING: contains banned part
--- Begin Message ---Someone suggested I should have pointed out that in my experience there exists policies that do not typically indicate a requirement for "high assurance," not because we aren't serious about them, but because IA technology does not yet offer a known good strategy to enforce them with any degree of certainty, like we can with military-oriented "No Flow Down." Examples are so-called "Integrity" (whatever that is) and "Availability". -John-----Original Message----- From: [email protected] on behalf of Davidson, John A. Sent: Mon 5/23/2011 7:06 AM To: [email protected] Subject: Re: [cicm] BoF Request for CICM at IETF 81 The conventional COMPUSEC view of high assurance was that - it was indicated where the Policy had to be enforced for certain (mandatory) e.g. no flow down tolerated. ----- Original Message ----- From: [email protected] <[email protected]> To: CICM Discussion List <[email protected]> Sent: Mon May 23 05:27:45 2011 Subject: Re: [cicm] BoF Request for CICM at IETF 81 Richard, On 2011-05-22 at 06:36, Richard Graveman wrote: > It seems to me that high assurance may well be needed in cases with > only one domain. Is that out of scope? Single domain use cases are definitely in scope; but they are very similar (conceptually) to existing commercial crypto APIs. The ability to separate domains is what sets CICM apart. See: "2.3. Single Security Domain" in CICM Logical Model http://tools.ietf.org/html/draft-lanz-cicm-lm-00#section-2.3 "18. Single-Domain" in CICM Channel Management http://tools.ietf.org/html/draft-lanz-cicm-cm-00#section-18 Lev _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm<<winmail.dat>>
--- End Message ---
_______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
