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

Jira Issues

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

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.