RE: Welcome to the security considerations list

["Lerner, Michah, ALSVC" <michah@att.com>]

I realize this was intended for Jeremy, but I'd like to express my view that
Security considerations should concentrate on risks, assumptions, and areas
of further work that may not be achievable within the formal specification. 

Consider specifically the use of cached credentials.  From the requirements 
perspective one might state:
  "Entitlements MAY indicate the acceptability of cached credentials 
   as authoritative.  The default is non-acceptance of cached credentials. 
   The suggested method is an URI that presents the terms and conditions 
   of the parties and the responsibilities for use of such credentials. 
   The URI is specified as ..."

From the security considerations perspective this is rather different:
  "Credentials may be authoritative or non-authoritative.  Authoritative
   credentials may be considered secure only when used in accordance with
   the appropriate practices.  Non-authoritative credentials may not be
   considered secure even in this regard.  Cached credentials may be
   authoritative for suitable practices.  OASIS does not currently certify
   any credential. Deployments may reference RFC-2527 for baseline
practices." 


-----Original Message-----
From: Edwards, Nigel [mailto:Nigel_Edwards@hp.com]
Sent: Tuesday, January 16, 2001 2:00 PM
To: 'Jeremy Epstein'; security-consider@lists.oasis-open.org
Subject: RE: Welcome to the security considerations list




> 
> In any case, I see the primary role of the group as providing general
> security review to make sure that the requirements, 
> specifications, etc.
> from the other groups don't have security architectural 
> problems (e.g.,
> broken crypto protocols).  A secondary role is to develop a set of
> guidelines for implementers about security considerations 
> that aren't part
> of the specification per se, but are necessary to have a secure
> implementation (e.g., tokens need to be cryptographically 
> random, which
> can't be required, but an implementation that doesn't do it 
> would be bad).
> 
Hi Jeremy,
What is your view on the relationship of the security considerations
group to the requirements group? I had been assuming the requirements
group would focus on application scenarios and that the security
consideration group might discuss and make recommendations on 
specific security requirements.

Regards,
Nigel.