Issues for Common Secure Interoperability Version 2 RTF mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 3906: CSIv2 Protocol
Issue 3922: GSSUP Names are inconsistent other security mechanisms.
Issue 3932: Service ID missing
Issue 3948: GSSUP names are incompatible with the Identity Token
Issue 3972: Format of GSSUP GSS exported name object undefined
Issue 3973: inconsistent definition of target_name field
Issue 3974: CSIv2 IOR Tagged component Identifier values
Issue 3975: INVALID recommended cipher suites
Issue 4118: Multiple Privilege Authorities and Supported Naming Types
Issue 4141: ISL changes to break dependency on Security and SECIOP modules
Issue 4142: Module suggestions
Issue 4143: OIDs
Issue 4200: Module SSLIOP Does Not Contain Host
Issue 4221: Issue: inconsistent definition of AuthorizationToken
Issue 4268: How to Partition the ServiceConfiguration syntax space to support vendor sp
Issue 4277: New minor codes for NO_PERMISSION Exception in CSIv2
Issue 4281: No Tokens in EstablishContext Message
Issue 4282: Inability to specify per method target security requirements
Issue 4293: CSIv2 Issue: SECIOP does not have multiple addresses.
Issue 4308: The encoding of GSSUP ICT's is not clearly specified
Issue 4326: CSIv2 TSS state machine lacks states to enforce target policy for
Issue 4327: clarification of csiv2 stateful conformance requirements
Issue 4330: How to Partition the AuthorizationElementType regarding vendor extensions

Issue 3906: CSIv2 Protocol (csiv2-ftf)

ssue on Document orbos/2000-08-04, CSIv2 Joint Submission:

Document: orbos/2000-08-04 CSIv2 Joint Submmission
Subject: Protocol and IOR incompatabilities for Identity Assertion
Severity: Critical

Summary:

The CSIv2 protocol is too vague on acceptance of identity tokens.
This yeilds an uneeded and unwarranted complexity in implemenations.
Vague protocols are not a good idea. It limits interoperability.

Discussion:

In the IOR, the CSIv2 protocol states a list of OIDs signifying the
acceptable forms of an IdentityToken delivered by the client. This list of
acceptable name forms is stated only to apply to GSS_NT_ExportedName
types. There are no OIDs signifying that an X.501 DN or X.509 Public Key
Certificate are acceptable.

It seems that the specification is written so that both X.501 DNs and
X.509 Certificate chains are always acceptable. This requirement would
cause all clients to send only X.501 DNs or X.509 Certificate Chains,
regardless of the server listing its acceptable name types. Also, there is
no indication of which of an X.501 DN or X.509 Public Key Certificate
Chain is desirable. This is vague.

It is completely unwarranted to tell all CSI mechanisms that they must
support X.509 DNs or X.509 Certificate chains. These name forms may not be
relevant to the mechanism at all. The mechanism may not support public key
technology, have facility for verification of certificates, may not be
able to parse X.501 DNs or X.509 Certificate Chains, and further more, but
not least, the security mechanism may not know what to do with it. One
example, might be an TCPIP CSI mechanism that only wants to accept
Kerberos principal names, Unix user names, or NT user names. DNs or
Certificate Chains are irrelevant.

With that in mind, a client should not be allowed to send the server an
X.509 certificate chain or an X.501 DN at it. Those name forms are not
acceptable to the server.

The easiest way around this problem is to allocated OIDs under the OMG OID
that signify the acceptance of each of the X.509 DNs and X.509 Public Key
Certificate chains. Servers that accept X.501 DNs and X.509 Public Key
Certificate chains for identity assertion shall list the appropriate OIDs
in the IOR.

Document: orbos/2000-08-04 CSIv2 Joint Submission
Subject: GSSUP Names are inconsistent other security mechanisms.
Severity: Medium

Summary:
The names supplied in the InitialContextToken for the UserName password
scheme invents a name type called a Security::ScopedName. This is just yet
another name type that must be dealt with and is completely inconsistent
with anything else used for names. The contents of the scope and the name
are underspecified.

Discussion:
The structure should allow for all forms of name types. The easiest 
way to do accomplish consistency is to use a GSS exported Name type.

        struct InitialContextToken {
                Security::GSS_NT_ExportedName username;
                Security::UTF8String          password;
        };

That way a password database can even store names that are DN's,
X509GeneneralNames, Kerberos Names, NT Usernames, etc.

        CSIV2 service context element, SecurityAttributeService,
must be assigned a service id.

Description:

    const ServiceId SecurityAttributeService = xx;

    A numerical value must be reserved within the OMG service
id space to identify CSIv2 service context elements. The
value will replace the temporary value ("xx") appearing in the
submission.

Discussion:

Proposed Solution:

    const ServiceId SecurityAttributeService = 15;

The name type used in the GSSUP mechanism for Client Authentication over
the transport name type is not convertible to anything used by the
Identity Token. This situation becomes a problem when on the server side
where you need to quote, (i.e. identity assert) the client's authenticated
identity to another CSIv2 CORBA outcall on behalf of the client.

The solution is to change the GSSUP name type to a GSS_NT_ExportedName
form, where it can easily be lifted. This is also the subject of another
previous issue raised about GSSUP name types. This solution will solve
both problems.

Document: orbos/2000-08-04 CSIv2 Final Submission
Issue: 

Format of GSSUP GSS mechanism-independent exported name object, a
special form of "flat" name as described below, is not defined.

Description:
        
>From RFC 2473 section 1.1.5 Naming

> Different classes of name representations are used in conjunction
> with different GSS-API parameters:
> 
>       - Internal form (denoted in this document by INTERNAL NAME),
>       opaque to callers and defined by individual GSS-API
>       implementations.  GSS-API implementations supporting multiple
>       namespace types must maintain internal tags to disambiguate the
>       interpretation of particular names.  A Mechanism Name (MN) is a
>       special case of INTERNAL NAME, guaranteed to contain elements
>       corresponding to one and only one mechanism; calls which are
>       guaranteed to emit MNs or which require MNs as input are so
>       identified within this specification.
> 
>       - Contiguous string ("flat") form (denoted in this document by
>       OCTET STRING); accompanied by OID tags identifying the namespace
>       to which they correspond.  Depending on tag value, flat names may
>       or may not be printable strings for direct acceptance from and
>       presentation to users. Tagging of flat names allows GSS-API
>       callers and underlying GSS-API mechanisms to disambiguate name
>       types and to determine whether an associated name's type is one
>       which they are capable of processing, avoiding aliasing problems
>       which could result from misinterpreting a name of one type as a
>       name of another type.
> 
>       - The GSS-API Exported Name Object, a special case of flat name
>       designated by a reserved OID value, carries a canonicalized form
>       of a name suitable for binary comparisons.

Section 3.5 of the CSIv2 document describes Identity Tokens, however it
did not describe the format of the "name blob" (that is the part
following the mechanism OID and length) within a GSSUP Exported Name
Object.

Document: orbos/2000-08-04 CSIv2 Final Submission
Issue: 

target_name(s) field of struct AS_ContextSec is defined and described
inconsistently in various places in the submission.

Description:

In section 6.1.4.1 this field is defined as 

	sequence <Security::GSS_NT_exportedName> target_names;

and defined as a list of target names.

In the IDL in section B.7 this field is defined as

	sequence <Security::GSS_NT_exportedName> target_name;

There are other places in the document where the singular form of this
field name is used, including in the examples of the scenarios chapter.

Proposed Solution:

The change of this field to a list was not necessary, as it is difficult 
to make a case for requiring multiple target names within a single
mechanism (as there is a multiple mechanism workaround).

We should at least fix the inconsitencies in the document. If we keep
the
ability to express multiple targets, then we should also say something
about the semantics of position in the list.

The prefered solution would be to revert back to the singular form.

	Security::GSS_NT_exportedName target_name;

and fix all references to this field accordingly.

Document: orbos/2000-08-04 CSIv2 Final Submission
Issue: 
        tagged component identifier values must be assigned for
        components TAG_NULL_TAG, TAG_CSI_SEC_MECH_LIST, and
        TAG_SECIOP_SEC_TRANS.

Description:
        
        const IOP::ComponentId TAG_CSI_SEC_MECH_LIST = aa;
        const IOP::ComponentId TAG_NULL_TAG = bb;
        const IOP::ComponentId TAG_SECIOP_SEC_TRANS = cc;

    Numerical values must be reserved within the OMG tag list to
identify these new tagged components. These values will replace the
temporary values, "aa", "bb", and "cc" appearing in the submission. 

Discussion:

Proposed Solution:

	const IOP::ComponentId TAG_CSI_SEC_MECH_LIST = 33;
        const IOP::ComponentId TAG_NULL_TAG = 34;
        const IOP::ComponentId TAG_SECIOP_SEC_TRANS = 35;

TAG values for aforementioned constants allocated by OMG and incorporated 
in the IDL editorially.

Document: orbos/2000-08-04 CSIv2 Final Submission
Issue: 

Section "5.2.1" Recommended SSSL/TLS Ciphersuites" incorrectly names 4
cipher suites.

Description:
        
The first 4 cipher suites in the recommended list do not exist as they
were named. The invalid appearing in this list are:

TLS_RSA_EXPORT_WITH_RC4_128_MD5
SSL_RSA_EXPORT_WITH_RC4_128_MD5
TLS_DHE_DSS_EXPORT_WITH_DES_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES_CBC_SHA

Proposed Solution:

Replace the invalid names listed above with the following:

TLS_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_MD5
TLS_DHE_DSS_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA

Multiple privilege authorities and multiple naming types yield
combinatorial problems for the client.

Discussion:

This issue is sort of in the same regards to Issue 3973 where Ron thinks
that having multiple target_name(s) in the AS_ContextSec is a bad idea, of
which I agree.

The type of the privilege_authorities field in the CSIIOP::SAS_ContextSec
structure sequence<ServiceConfiguration>. It suffers the same problem,
especially when combined with multiple supported naming types.

It is completely hard to determine having multiple privilege authorities
and the names that must be used to assert the identity for the privileges.
In fact, the client may get back an AuthorizationToken that he doesn't
understand, but will need to assert an identity for it's use, quite
possibly with endorsement. Having multiple naming types supported per
privilege authority is fine, but combine that with multiple ones, and you
may get a decision problem for the client.  

It is better to be able to specify a one-to-one correspondence, locking
down the combinations that a server will accept, and the client doesn't
have to do any mucking about deciding what will work.


Proposed Solution:

Singularize the privilege authorities field.

Unfortunately IDL has a hard time making a singular field become optional
without doing something bizzare, such as:
	switch(boolean) {
		true: ServiceConfiguration privilege_authority
	}
which requires a new type, etc.

I have two proposals:

Proposal 1: 

We signularize the field in name, i.e.  "privilege_authority". Keep the
sequence definition. However, stating in the specification at most one
must be contained. This can be hinted at as well in IDL.

struct SAS_ContextSec{
	Security::AssociationOptions    target_supports;
	Security::AssociationOptions    target_requires;
	sequence <ServiceConfiguration,1> privilege_authority;
	sequence <Security::OID> supported_naming_mechanisms;
};


Proposal 2:

We specify a ServiceConfigurationSyntax tag for "none", and specify that
the sequence of octet associated with it is empty.

// Corresponding ServiceName for the SCS_None Syntax should be an empty
// sequence octets.
const ServiceConfigurationSyntax SCS_None = -1;

struct SAS_ContextSec{
	Security::AssociationOptions    target_supports;
	Security::AssociationOptions    target_requires;
	ServiceConfiguration  privilege_authority;
	sequence <Security::OID>   supported_naming_mechanisms;
};

For efficiency I'm in favor of the second approach, because I can just
look a the ServiceConfiguration::syntax field and know what to do. The
first proposal causes me to look at the length first, index to the first
element in the array, and then look at the syntax field.

As an aside, I also wouldn't mind changing the sequence<Security::OID>
type into a Security::OIDList, but that can be the subject of another
issue. Also note, to be specific with the document I am pointing to, I
used the "Security" definitions. Hopefully, we will follow one proposal to
change the Security::AssociationOptions to CSIIOP::AssociationOptions and
Security::OID and Security::OIDList to CSI::OID and CSI::OIDList
respectively.

Document: orbos/2000-08-04 CSIv2 Final Submission
Issue: 

Section "IDL" Contains dependencies on the IDL of the security
specification (the SECURITY, SECIOP, and SSLIOP modules)

Description:
        
The IDL for CSIv2 is dependent on the AssociationOptions type of the
SECURITY module, and proposes some new types to be added to that module.

The IDL for CSIv2 also proposes some new types to be added to the the
SECIOP module.

The IDL for CSIv2 is dependent on the SSL module.

Proposed Solution:

1. Move the AssociationOptions type out of the Security Mododule into a
new base security module. (Issue for the security spec) - Make the
Security Module dependent on this base security module.

2. Add new constants to AssociationOptions.

3. Add to this new base module the new types created for CSIv2 and
previosly intended to be added to the security module (with the
exception of the types related to type ScopedName, which will be the
subject of another issue).

4. Move the new SECIOP ComponentId and tag structure for TAG_SECIOP
SEC_TRANS into the CSIIOP module, thus eleiminating the CSIv2 dependence
on the SECIOP module.

5. move the SSLIOP module into the CSIv2 spec. Change the SSLIOP modules
dependency on the security module to a dependency on the new base
security module. 

6. Change All references to the SECUIRTY module in modules GSSUP,
SSLIOP. CSI, and CSIIOP to references to the base security module.

7. Modify the GSSUP, CSI, and CSIIOP modules for idempotent inclusion.

Elimination of dependencies on the Security, SECIOP, and SSLIOP modules 
is generally felt to be a good idea. Move pertinent data definitions from Security, 
SECIOP, and SSLIOP into CSI module and CSIIOP module.

In looking at it, I think CSI would make a good "base" module.

Since other modules are only related to CSI, such as CSIIOP and GSSUP, I
see no reason why those two modules cannot depend on CSI.

Define in CSI:

AssociationOptions
GSSToken
GSS_NT_ExportedName
X509CertificateChain
X501DistinguishedName

As part of another issue, change the use of ScopedName in GSSUP to
CSI::GSS_NT_ExportedName.

As yet another issue, is to get rid of the ASN.1 dependance on
X509CertificateChain and X501DistinguishedName and somehow make it
consistent with the PKI spec. Or get rid of them all together, and just
use ExportedName format with proper OIDs.

There is a need to define OIDs, at least one for GSSUP. However, an OID is
represented by a sequence of positive integers, encoded as a octet
sequence. The encoding has the property that two encodings are equivalent
if and only if their definitions are equivalent (which is something ASN.1
DER is not particulary good at).

We cannot define a costant in IDL for a sequence of octets. However, I've
seen an number of ASN.1 compilers and it seems that the internal form of
the definition of an OID is a string of natural numbers in base 10
separated by dots. This is a parseable representation, and widely used.

I suggest that we introduce a definition, possibly a type, for and OID
string representation.

	module CSI {
		//
		// An OID String Representation.
		// The OID is represented in dot format.
		// For example, "2.23.130.1.1.1".
		//
		typedef string OIDStringRep;
	};

	module GSSUP {
		const OIDStringRep GSSUP_OID_DEF = "2.23.130.1.1.1";
	};

This will allow ASN.1 compilers to at least map from this internal string
representation if they don't already do so.

What do you think? If there is consensus, I'll raise an issue, and we can
resolve it.

OIDs are usually expressed in documents and programming tools as base 10 integers separated by dots, such as "2.23.130". It would be good to adopt something similar to this representation so that they can be represented as constants in IDL, as a sequence of octets does not have a constant representation in IDL. 
A typedef created to handle this will be: 

    typedef string StringOID; 

We use the term "StringOID" because already have an "OID" type in the CSI module, and in the spirit of the CosNamingExt module, it is analogous to the "Name" and "StringName" types and their definitions. 

In some situations, e.g. a multi-homed system, there would have to be a profile for each port number supported by SSL.  This is inefficient.  Adding a String host_name to the struct SSL in the Module SSLIOP would resolve this issue.

We add a minor section describing a TransportAddress structure with wording
close to that of the IIOP profile on page 15-50 of CORBA 2.3. formal/99-10-07.
We also add a typedef for a sequence of these structures. We change the
TLS_SEC_TRANS structure to use a list of these addresses.

Document: csiv2-011701

In section 16.2.3

The AuthorizationToken type is defined inconsitently with respect to its
definition in IDL module CSI.

typedef sequence <X509AuthorizationElement> AuthorizationToken;

in module CSI

typedef sequence <AuthorizationElement> AuthorizationToken;

The definition in 16.2.3 should be chnaged to agree with that in the IDL

We need to define how the namespace of ServiceConfiguration syntax
identifiers (used in privilege_authorities) is to be partitioned 
so that individual vendors have some identifiers reserved for
their use (i.e. the definition of vendor specific syntaxes).

How to Partition the ServiceConfiguration syntax space to support vendor specific extensions

Don,
>
> Although the minor codes of the NO_PERMISSION exception have been defined
> in Table 4-7,  Section 4.5, of the 7/21/2000 version of the CSIv2
> Specification, in order
> for the server to properly communicate the caused of the NO_PERMISSION
> exception
> to the client,  we would like to propose the additional minor codes to the
> NO_PERMISSION
> exception.
>
> ***********************************************************************
> NO_PERMISSION authentication error minor codes:  range 1-100
> (Note:  The following minor codes are  defined in the current CSIv2 spec:
>
> 1 - Invalid evidence
> 2 - Invalid mechanism
> 3 - Conflicting evidence
> 4- No Context
> )
> The new proposed minor codes for NO_PERMISSION exception:  The numbering
> scheme was chosen to group errors into areas of
> similarity.
>
> 5 - user id not defined to security system - the user may select another
> userid
> 6 - user id revoked by security system - the user may select
> another userid
>
> 11 - password invalid for this userid - the user may correct the password
> 12 - password expired - the user may select another userid
>
> 20 - credentials expired - the user may select different credentials or
> renew them(e.g. by reissuing kinit)
> 22 - credentials invalid - the user may select different
> credentials, (e.g.
> by kinit, or specifying a different PKCS certificate handle)
>
> 52 - new password doesn't meet installation requirements
>
> 60 - general authentication error - the user should resubmit his
> credentials, but not additional information as to what is in error is
> provided.
> ******

CSIv2 will not define a new exception minor code. The CSIv2 ContextError codes 
will be modified to support future inclusion of additional and optional error 
codes in the point-to-point, wire-level exchange between TSS and CSS. An error 
token and minor status codes will be defined for the GSSUP mechanism. 
Communicating error status from the CSS to the client app, will be defined in 
the context of APIs (that is, above the wire-level interoperability defined by 
the current specification).

The spec doesn't say whether or not an EstablishContext with none
of cleint authentication, identity, or authorization token is
legitimate.

I don't think we need the ability to send such mecahnisms (for
unprotected requests), as we would just send the request without a CSIv2
service context element. The only down side I can see, to writing this
empt EstbalishContext out of spec, would be that a client could not use
it to get feedback from a TSS in the form of CompleteEstablishContext,
indicating that the TSS supports CSIv2.

We must indicate that this is either an invalid msg, or state that it
must be supported (and what it's semantics should be).

Table 16-4 includes entries which correspond to empty EstablishContext 
messages, so I now believe that we have adequately defined the semantics of 
such messages. In retrospect, what is missing from the spec, is the protocol 
behavior when CSIv2 is used without SAS. I have created a new issue (with 
proposed resolution) to address that issue.

The CSIv2 mechanism definition schema, soes not provide a way to
associate mechanisms with subsets of the methods of an object.

Discussion

EJB method-permissions may be associated with subsets of methods, such
that a class of EJB objects may have some protected and some unprotected
methods. Where by protection I mean, the caller must be authenticated
and be in a authorized role, to access the method. Some methods of an
EJB may be available to unauthenticated callers, while others may limit
access to only specific authenticated callers.

Given a mixed protection object, how would one define its IOR such that
it could be affectively accessed by its clients without

1. eliminating unauthenticated access to the object

   that is, mark the target as authentication required

2. causing unnecessary authentications and usurping the
   clients perogative to only authenticate when it is required to or
   chooses to.

   that is, mark the target as authentication supported and tell the 
   client to authenticate if it can

3. causing failed attempts because the client does not know that
   the target requires authentication

   that is, mark the target as authentication supported and let the 
   client authenticate if it wants to

Would it be appropriate to add information to the IOR, that indicates
that whether the object will check permissions, such that a client
normally operating in mode 3, would know when it would probably do
better in mode 2?

Should a CSIv2 IOR which principally defines (authentication and msg
protection mechanisms) carry additional information about the
authorization policy of the object? There is obviously some precedent
for doing so in the privilege authorities field.

This issue is the exactly the same issue as issue 4200, which
is for TLS (SSL) transport addresses. It notes that the
component for a SECIOP transport needs to support multiple
addresses.

The recommended solutioin to this issue is to adopt the analogous
resolution to the 4200 issue.

We add a minor section describing a TransportAddress structure with wording
close to that of the IIOP profile on page 15-50 of CORBA 2.3. formal/99-10-07.
We also add a typedef for a sequence of these structures. We change the
SECIOP_SEC_TRANS structure to use a list of these addresses.

Document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf

Isuse: The encoding of GSSUP ICT's is not clearly specified

Para 48 states:

[48] The format of a GSSUP initial context token shall be as defined in
[IETF RFC 2743]
Section 3.1, “Mechanism-Independent Token Format,” pp. 81-82. This
GSSToken shall
contain an ASN.1 tag followed by a token length, an authentication
mechanism
identifier, and a CDR encoded sequence of octets corresponding to a
GSSUP inner
context token as defined by the type GSSUP::InitialContextToken in
Section 16.9.2,
“Module GSSUP - Username/Password GSSAPI Token Formats,” on page 16-59
(and
repeated below).

and section 
16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats
states

// The following structure defines the inner contents of the username
// password initial context token. This structure is CDR encoded in a
// sequence of octets and appended at the end of the username/password
// GSS (initial context) Token.

struct InitialContextToken {
	CSI::UTF8String username;
	CSI::UTF8String password;
	CSI::GSS_NT_ExportedName target_name;
};

Proposed Resolution:

Change para 148 to the following:

[48] The format of a GSSUP initial context token shall be as defined in
[IETF RFC 2743]
Section 3.1, “Mechanism-Independent Token Format,” pp. 81-82. This
GSSToken shall
contain an ASN.1 tag followed by a token length, an authentication
mechanism
identifier, and an encapsulation octet stream containing a CDR encoded
GSSUP inner
context token as defined by the type GSSUP::InitialContextToken in
Section 16.9.2,
“Module GSSUP - Username/Password GSSAPI Token Formats,” on page 16-59
(and
repeated below).

change the relevant comment in 
16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats 
to the following

// The following structure defines the inner contents of the username
// password initial context token. This structure is CDR encoded in an
// encapsulation octet stream and appended at the end of the
username/password
// GSS (initial context) Token.

While in state "Waiting for Request", The TSS state machine will accept
an unprotected request, without consideration of the target CSIv2
security policy. 

Also the specification does not describe what is supposed to happen when
a target's mechanism definitions/policy requires SAS (i.e. client
authentication) and the CSS does not send an EC.

The specification is currently weak on its description of what must
be done by a TSS with respect to designating a "stateful" value in its
IOR's, and in defining under what circumstances a TSS may claim stateful
conformance. In particular, the spec does not currently state whether or
not a TSS must be stateful for all of its mechanism definitions, at all
of its target objects in order to claim stateful conformance. The
following paragraphs should be included to clarify these two issues.

the thing that is missing in the doc, is that we do not currently
have anything that says a TSS is required to set the stateful bit.

[99] A TSS that supports stateful contexts may negotiate a request to
establish a stateful context to a stateless context in order to preserve
resources. It may do so only if it does not already have an established
matching stateful context.

[100] Conversely, a stateful TSS that has negotiated a request to
stateless may respond statefully to a subsequent context with the same
(non-zero) client_context_id.

We have a description of what the bit means (in para 140) which focuses
on what a TRUE value means. Perhaps you are saying that we need a
description of what a FALSE value means. My sense is that the FALSE
semantics are clear enough.

[140] A value of TRUE in the stateful field of the CompoundSecMechList
structure indicates that the target supports the establishment of
stateful or reusable SAS contexts. This field is provided to assist
clients in their selection of a target that supports stateful contexts.
It is also provided to sustain implementations that serialize stateful
context establishment on the client side as a means to conserve precious
server-side authentication capacity.10

10.This serialization is only done when an attempt is being made to
establish a stateful context.

The last part of 140 says that if the stateful bit is true, some CSS
implementations will not send multiple concurrent requests to establish
the same stateful context. This design changes the multithreaded nature
of the client app (for the round-trip time of one request) in exchange
for not wasting the resources of the TSS. What it really says is that
the serialization is acceptable if it only occurs when the bit is true,
as one way or another, multiple requests should be serialized until the
stateful context is established. In one design the serialization happens
at the CSS, and in the other (if it occurs, it is done) at the TSS. This
hint, was strongly argued for, because without it CSS side serialization
would be at a disadvantage because it would happen in too many cases
where it could come to no benefit.

We have decided to let the (stateful) conformance statements stand as
they are written.
Resolution:

We should define how the namespace of AuthorizationElementType 
identifiers (used in authorization tokens) is to be partitioned 
so that individual vendors have some identifiers reserved for
their use (i.e. the definition of vendor specific type identifiers).

The resolution to Issue 4268 (How to Partition the ServiceConfiguration syntax 
space to support vendor specific extensions) should be applied to the 
AuthorizationElementType identifier. 
This resolution also corrects an error in the resolution to issue 4268 as 
described in items 5 and 6. It consists mainly of declaring the OMGVMCID 
constant in the CSI module instead of in the CSIIOP module as was originally 
done in the resolution for 4268.