Promote "Optional Signature" to Requirement

[George_Robert_Blakley_III@tivoli.com]

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.