OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: XACML TC Charter Revision - Strawman


Yes, SAML has a security and privacy considerations sub group (and spec
chapter). I see that XACML has not established such a group. We certainly
should do so.

On a theoretical note, human activities are inherently imperfect. Safety
engineering tries to prevent errors and minimize their effects. However in
the security business you always have to start by assuming something works
(at least mostly) or else there is no place to stand. This is the true
technical meaning of "trusted." A prime example is the TCB concept.

In my former life as a consultant, I remember several conversations in which
the person I was talking to was making such drastic assumptions about the
untrustworthiness of certain components, that it seemed impossible to make
any statement about the security properties of the system in question.
Security is a form of risk management and it is necessary to weigh both the
probability of compromise and its impact.

Hal

> -----Original Message-----
> From: bill parducci [mailto:bill@parducci.net]
> Sent: Friday, June 08, 2001 4:21 PM
> To: 'xacml@lists.oasis-open.org'
> Subject: Re: XACML TC Charter Revision - Strawman
> 
> 
> what i am saying is that you cannot GUARANTEE this is the case. if i
> remember correctly, just a few months ago verisign issued a 
> cert for one
> of microsoft's sites to an unauthorized entity -- things like 
> that kinda
> hinder utter faith in the authentication layer alone, don't you think?
> add that to the unavoidable latitude for specific vendors and users
> during implementation of whatever spec comes out of this group and you
> have the *possibility* of compromise.
> 
> if you can make the case that it is impossible for this to happen
> (which, from an academic perspective, is not possible because 
> one cannot
> prove 'non existence'), then the the balance between effort of
> implementation of discrete responses vs. the likelihood of 
> compromise is
> an easy one. otherwise, i suggest that we at least perform 
> due diligence
> in determining what the ramifications of discrete response codes are. 
> 
> i have no interest in one direction or the other, i just want to make
> sure that the issue is raised.
> 
> b
> 
> Hal Lockhart wrote:
> 
> > Excuse me. Are you saying that no means exists whereby a 
> PEP and PDP could
> > mutually authenticate and exchange integrity and 
> confidentiality protected
> > data over an insecure network?
> > 
> > Hal
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC