re:ASN.1 ambiguity

["danielle (d.m.) mortimer" <[e-mail]>]

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