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@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

---

From: Bancroft Scott[SMTP:baos@oss.com] Sent: 30 June 1998 21:21 To: Pete Cordell Cc: 'ITU-SG16@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@oss.com Tech Support :1-732-249-5107 http://www.oss.com Fax :1-732-249-4636