RE: Promote "Optional Signature" to Requirement

[Philip Hallam-Baker <pbaker@verisign.com>]

Bob,

	The idea of the ESA requirements analysis scheme is to uncover the
requirements that tend to be embedded in architecture. It is not a question
of requirements having higher status than architecture. Each architectural
statement must be supported by a requirement statement. Each requirement
statement must either have one or more architectural elements that satisfy
it or an explanation as to why it was not met. The idea is that the
architecture contains all the statements that make it into code:-)

	The basic idea of the analysis is to be able to identify the reasons
behind the design after the fact. A big problem with IETF specs is that a
lot of the design rationale is lost and you have to find someone from the
original team if you want to fiddle with it. This in turn leads to
superstitious treatment of features whose justification is long gone or
inapplicable.

	We can try a different method of structuring the dialogue on the
list. However I am anxious to avoid the typical IETF approach in which
requirements, design elements etc are all thrown onto the list and have half
of them forgotten in the drafts...


	I would add the following two requirements:-

[R-IntraDomain] Efficiently support communication of auth data intra domain.
	{describe bob's scenario here}

[R-IdentifyMessages] Distinguish between messages from different versions of
the protocol.


Then add in Bob's solutions to the problems in the architecture piece pretty
much as is.

An alternative solution to [R-IdentifyMessages] is to use the XML name
space.

		Phill

> -----Original Message-----
> From: George_Robert_Blakley_III@tivoli.com
> [mailto:George_Robert_Blakley_III@tivoli.com]
> Sent: Thursday, January 25, 2001 5:30 PM
> To: Philip Hallam-Baker
> Cc: security-core@lists.oasis-open.org
> Subject: Promote "Optional Signature" to Requirement
> 
> 
> Phil et. al.:
> 
> I'd like to propose that Optional Signatures is a 
> requirement, not just an
> option.
> 
> Here's the justification:
> 
> [R-Optional-Signatures]  Name assertions and property assertions are
> statements by an authority about the validity of
>                asserted values of name-value pairs.  It 
> should be possible
> to tailor the mechanism of assertion
>                to both the threat environment and other 
> constraints.  Thus,
> if the assertion is coming from a
>                directory to a boundary server, in response to a user
> contacting the boundary server and proving
>                his/her name, and if the link between the 
> directory server
> and the boundary server is known to be
>                strongly protected, and if the boundary server 
> trusts the
> directory's authority, there should be no
>                need for a signature *or any other protection* 
> applied to
> the assertion token.  Furthermore, there
>                is a good reason NOT to apply a signature or other
> protection, as it will degrade performance and
>                impose a requirement for the boundary server and the
> directory to share a key distribution mechanism.
>                This example generalizes to many others.
> 
>                The requirement therefore is to
> 
>                (1) Include in the assertion token structures 
> an OPTIONAL
> signature field, which will syntactically
>                accomodate both public-key signatures and symmetric-key
> mechanisms, and
> 
>                (2) Require protocol bindings to state whether 
> use of this
> field is mandatory in the context of
>                the particular binding, and
> 
>                (3) Require protocol bindings to state which 
> mechanisms MUST
> be supported, which mechanisms
>                MAY be supported, and which mechanisms MUST NOT be
> supported.
> 
> While I'm at it, I'd like to propose another requirement:
> 
> [R-Versioned-Tokens]     All assertion tokens defined in this 
> specification
> should include "version" as a required field.
>                The version format should permit designation 
> of both major
> versions and minor versions within
>                major versions.  The version of tokens defined in this
> release of the specifications should be
>                1.0.
> 
> --bob
> 
> Bob Blakley
> Chief Scientist, Security
> Tivoli Systems, Inc.
>