re:ASN.1 ambiguity

[John Lowry <[e-mail]>]

> Subject:  re:ASN.1 ambiguity 
> 
> In message "ASN.1 ambiguity", [e-mail] writes:
> 
> > I have a problem with the ASN.1 defintion of InitialContextToken as found
> > in draft-ietf-cat-spkmgss-04.txt (May 25, 1995):
> > 
> >    InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
> >            thisMech        MechType,
> >                    -- MechType is OBJECT IDENTIFIER
> >                    -- representing "SPKM-1" or "SPKM-2"
> >            innerContextToken ANY DEFINED BY thisMech
> >                    -- contents mechanism-specific
> >            }
> > 
> > Since the "thisMech" component may only assume one of the values
> > SPKM-1 or SPKM-2, it does not unambiguously determine the actual type 
> > governing the value in the "innerContextToken", which may be 
> > SPKM_REQ, SPKM_REP_TI, SPKM_REP_IT, or SPKM_ERROR. I understand that the
> > various context establishment tokens are distinguished by their
> > tok_id fields; however, the distinction should be accomplished at an earlier
> > stage during decoding, i.e. through the value of "thisMech".
> >
> > Has anybody come across this problem, or am I wrong?
> 
> I'll answer on behalf of Carlisle who is on vacation at the moment.
> 
> This is not a problem at all.  The mechanism type is intended to
> indicate the mechanism, e.g. SPKM-1, SPKM-2, Kerberos V5, etc.  The
> decoder must read the mechanism type before it can interpret the
> mechanism-specific contents of the innerContextToken.  In the case of
> SPKM-1 and SPKM-2, the innerContextToken is ASN.1-encoded, and the token 
> type is indicated by the tok_id field as you pointed out.  The decoder 
> then has to "peek" at the tok_id before it can interpret the contents as 
> SPKM_REQ, SPKM_REP_TI, SPKM_REP_IT or SPKM_ERROR.
> 
> -------------------------------------------------------------
> D.M. Mortimer                   Nortel Secure Networks
> email: [e-mail]          2 Constellation Crescent
> voice: [phone]           Nepean, Ontario K2G 5J9
>   fax: [phone]           http://www.entrust.com
> 
I disagree entirely on the ASN.1 specification:

	The mechanism type must resolve to a single ASN.1 type.  The syntax
	of this type must be specified in the ASN.1 specification.  If it
	is some application-specific structure, then it must be encapsulated
	within some ASN.1 defined type - e.g. OCTET STRING.  Ask Warwick why
	X.509 extensions have the type and then an OCTET STRING.

	In other words, there is no peeking.  The syntax of the defined
	element is 1) completely unambiguous and 2) resolvable to a
	built-in or user-defined ASN.1 syntax.  You cannot specify that
	if thisMech == foo then innerContextToken is a memory image of
	a C structure.  You could, however, specify that innerContextToken
	is an OCTET STRING and have it known by convention that the
	contents of that OCTET STRING are the memory image of a C structure.

	In the case above I would suggest that SPKM-1 and SPKM-2 be
	defined to resolve to a CHOICE type that contains one of
	SPKM_REQ, SPKM_REP_TI, etc.

John Lowry