ASN.1 accross revisions

[Pete Cordell]

Bancroft and others,

I take your point that putting a second piece of ASN.1 into the UUIE may
jeopardize backwards compatibility.  I have to admit that I have to try
quite hard to read H.225 in such a way that it allows me to do this (but
it is possible!!!).  The basic issue is whether having read and decoded
the ASN.1 in the UUIE, implementations check whether all characters in
the UUIE have been used.  I guess only a poll of vendors would determine
whether this is the case.

An alternative to adding on an extra piece of ASN.1 in the case of the
Q.931 side would be to hi-jack one of the other IEs that we are unlikely
to use, and use that for the signature values.  For example one that we
might use is "Packet Layer Binary Parameters" which has an IE value of
0x44.

Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================


>----------
>From:  Bancroft Scott[SMTP:baos at oss.com]
>Sent:  30 June 1998 21:21
>To:    Pete Cordell
>Cc:    'ITU-SG16 at MAILBAG.INTEL.COM'
>Subject:       RE: ASN.1 accross revisions
>
>On Tue, 30 Jun 1998, Pete Cordell wrote:
>
>> I admit that I am only just hanging in there with this debate, but I
>> think I have a possible solution 5 to throw in as a contender.
>>
>> Looking at the problem a bit laterally, we have RasMessage in UDP
>> packets that we want to sign, and H323-UserInformation in the UUIE that
>> we want to sign.  Currently these are the only chunks of ASN.1 in these
>> fields.
>>
>> We could add a second piece of ASN.1 into these fields (UDP packet and
>> UUIE) that contains the signatures, such as:
>>
>> H323Extra ::= CHOICE
>> {
>>      icv     ICV,
>>      ...
>> }
>>
>> This would be a separate ASN.1 tree.  Therefore in a RAS UDP packet you
>> would get:
>>
>>      RasMessage chunk of ASN.1
>>      H323Extra chunk of ASN.1 typically containing signature
>>
>> Similarly in the UUIE, you would have
>>
>>      H323-UserInformation chunk of ASN.1
>>      H323Extra chunk of ASN.1
>>
>> Note that all the key ids and time stamps etc., would remain in the
>> RasMessage and H323-UserInformation parts (so they get signed).
>>
>> I agree this is not beautiful, but it does not require multiple ASN.1
>> encodings, and doesn't radically change the format of the message
>> depending on whether you want to sign it or not (as solution 4 seems
>> to).
>
>This crossed my mind a couple days ago, but it is not clear how this
>would
>be backward compatible.  That is, how would an older version handle
>this
>added information that comes after the H323-UserInformation?  I like
>the
>general idea, but if I am not mistaken it is not backward compatible.
>
>I have an idea as to how to do as you suggest in a backward compatible
>manner, but before I go down that path I need to know the answer to
>the question: Are the most recent implementations that know of H.323
>required to transmit an ICV with each RasMessage or
>H323-UserInformation?
>
>------------------------------------------------------------------------
>--
>Bancroft Scott                                Toll Free
>:1-888-OSS-ASN1
>Open Systems Solutions, Inc.
>International:1-609-987-9073
>baos at oss.com                                  Tech Support
>:1-732-249-5107
>http://www.oss.com                            Fax
>:1-732-249-4636
>
>