[Css-csts] Action A#03: Is there a need to change ISP1?

[Martin Götzelmann]

Members of the CSTS WG,

In response to action A#03 taken on the Berlin meeting I have looked into the ISP1 specification with respect to changes that might become necessary if we want to make this specification applicable to CSTSes.
 
The existing ISP1 specification has been prepared exclusively for SLE services and this becomes evident throughout the document:

*	the name of the protocol is "Internet SLE Protocol One"
*	throughout the document reference is made to SLE-PDUs
*	For data encoding the document explicitly references the ASN.1 specifications in the SLE books.

This is purely a formal aspect and could possibly be solved by just adding a statement in the CSTS Specification Framework that SLE Service should be considered equivalent to CSTS when using ISP1 for CSTS. Alternatively the wording in the ISP1 specification could be changed to refer to CSTS and to state that for ISP1 an SLE service is a CSTS.

The specification of the Data Encoding Layer is very short and in essence only contains 

*	A statement that the ASN.1 type specifications and BER encoding rules shall be used to translate operations to and from the transfer syntax (recall that the SLE specifications do not specify ASN.1 BER to be transfer syntax but leave this open)
*	A requirement that encoding or decoding failures shall be reported to the higher layers
*	The specification of how the credentials shall be encoded.

Obviously, the ISP1 specification says nothing about type extensions as this concept does not exist  in the SLE service specifications. One could possibly argue that EMBEDDED PDV is a standard ASN.1 feature and therefore we do not have to say anything special about it. On the other hand, some of the extended types are defined within the CSTS Specification Framework whereas others are not and at least a statement as to what falls under the responsibility ISP1 and what not does not would seem appropriate.

Possible options:

1.	ISP1 could be made responsible for encoding / decoding of types defined in the CSTS Specification Framework only (including all extensions defined there) and one could specify that the higher layers are expected to pass and receive the extensions as opaque data types;
2.	ISP1 could be made responsible for encoding/decoding of all FW types and all extensions outside the FW as long as the transfer syntax is ASN.1 - for all other types the higher layers would provide and accepts opaque types;
3.	ISP1 could be required to support encoding and decoding of all data regardless of the place of specification and of the transfer syntax used.
4.	One could remove data encoding and decoding completely from ISP1, but that would have a number of implications, e.g.:

		*	The authentication layer would have to be removed from ISP1 as well, because the operations must be decoded before they are authenticated

		*	The transfer syntax and the method of authentication would have to be specified within the CSTS Specification Framework (currently the same approach as for SLE services is being applied)

Options 2 and 3 would of course imply that an ISP1 implementation must be extended every time a new service shall be supported in the same way as this is done for SLE services. In addition, it might be considered adventurous to "import" a large number of specifications which to a large extent do not yet exist. On the other hand, the approach supports clean layering of the protocol layers. Option 4 would make ISP1 very stable but to some extent just move the problem to the CSTS Specification Framework. Option 1 might be the best compromise - implementers would anyhow be free to include further encoding/decoding into the ISP1 data encoding layer, because this would not be visible "on the wire".

As regards the basic question raised in the Action - do we need to change the ISP1 specification: I believe one could argue that it is not necessary, but changing the model to explicitly refer to CSTS concepts would certainly make the specification clearer.

Kind Regards,

Martin