>
> 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.